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Anrtexure F - Minimum Requirements and Technical Particulars ^ 


Artnexure Vl.b.4 


Backup Server 

» «V | . ' .ill 'S m 




Indian p«wer |0.V,Hz 

specifications in terms 
of Phase. Voltage. Freqj 


* 




r <v 


_^ , 


Processor Type (CISC. EPIC. RISC)]Same as Rack Server ICISC / EPIC / RISC 


lECC 


No, of channels the proposed 


RAID controller 

¥ » > I ~ l it I II H S ill fa ll! ft > I I W — 


Single 


■ -a. ■ * . 1 . <n»- -^ * y/iA^ 

I Single / Dual / Ouad 


Proposed sfcre of battery backed 


128 MB 


MB 


cache 

*in*ti«»i .Sifcalti 


Are Proposed Disks Hot Swappabie?|Y£S 

-a..*- ..... , . - ■ . ■ ... 


YES / NO 


Optical Qrtve Proposed 


DVD 


DVD Drkm 


, Is drive yyrrteabte / rewriteable? 




OVO-RAM 


■I 1 w 

YES 


YES / NO 


Lyes/no 

‘ . SiiMlii. ‘ 


YES I NO 

— - ■ • -- • ■■ • 

YES / NO 


YES 


8 JDLT Drive 

■■** > m i 


|YES/N<' 


No- SL gfflS£ proposed 


Format Compatibility 

..v r ii A.. ; 

SDLT 


9 (Network 

Type of Ethernet controller proposed (Full duplex (YES / NO 

_ 10/100/1000 Mbps 

No of Ethernet Controllers proposed | (Units 

2 




No. of ports on each Ethernet 
controller proposed 

|S>> * f. * yjj ___ 

Dual Hgmingproposed 


Single / Dual / Ouad 


YES / NO 


10 (Host based Adapters 

- - - 4 > „ v , „ , (* ■ I ... . C .. i«u_ 


Type of H8A proposed 


Full duplex Fiber 
channel 


Throughput of each of the proposed |4/8Gbps 
HBA 

1 **' . .. . ■*■1 1 11. lt ii r |i ,|| , i « , 

NO. of ports on each NBA proposed Single 


Gbps 


Single/Dual/Quad 

*-•» y ii 11 td 


f > h 


* * r v r i '» 

9 

r 


t, DOG 
rr* «* .* • r ’i * vi % 
J‘ •' * .Mt LI*.*' '*1, 

• ‘-j. ii * ■ *. t 
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% 



Backup Server 


Annexure Vl.b.4 




Parameter 


Minium 

Kttjtrfmnertts 


Total Throughput of all the proposed ) 8 Gbps 
HBA together 


fm h 

Unit cfMfe^uremtfrt 

*•* _ A 

$ '*M 


Gbps 


Capability to dynamically load 
balance between multiple HBA 
Support for storage subsystems of 
leading manufacturers like EMC. 
Hitachi. HP. IBM, SUN etc. 


YES / NO 

'*■» ' 1 i I'. I.Ui- 

YES/NO 


11 Any other software proposed (provide 
details] 

—V.i-J__ 

Backup software 


12 Sui 


[YES 


i .. ' '' ITWt 1 •> 1 -■ I, 

Is the proposed product/solution End]NO 
Of-ltfe or will reach End-of-lrfo 
within 24 months from the date of 
submission of bid Or 12 months from 

the date of acceptance, whichever is 
later'? 


Will the proposed product/solution 
reach End-of~support dunng the 

currency of contract? 

*** 1 — _* . 


[NO 


i 


YES / NO 


YES / NO 


YES/NO 



* 

# 

0 





Bid No. D-11018/14/Tec h/10-UlDAI 






Section VI - Minimum Requirements and Technical Annexure 




Annexure Vl.b.5 

Tape Library 


Nd 

. ' . 

Parameter 

■ 

V 

'V-** 

Minimum 

Requirement 

<» 

* Unit of 
Measurement 

r * 

i J 

Please mention devleBohe/lf 

i >/ — h - 

any 

f 

X 

t * 

1 

Power Specification 

Indian power 
specifications in 
terms of Phase. 
Voltage. Freq 

0.V.HZ 

... --- A 


2 

T ape Drives. 





Type of tape drive proposed 

tT OGttiA ■ - 

Lf>, - * ' 

jyiv * - ‘ ' , - ' 

i “ 

/ 

, 

y. , ' - ✓ “ f 

" r t ' 

% v .~ 1 

* * ^ * r v ' * , * . 


Type of tape drive interface 

Native fiber 
channel 




Sustained Data Transfer 
Rate (without compression) 

120 

MB/s 

. . - * ^ _ . JL « A . 


Sustained Data Transfer 
Rate (with compression) 

240 

MB/s 



Size of Tape Storage 
(without compression) 

800 




Size of Tape Storage 
(without compression) 

1500 

GB 



Hot Swappable Tape drive 
proposed 

YES 

YES i NO 



Hot Swappable Controller 
cards proposed 

YES 

YES / NO 


3 

Tape Library Frame 




_ 

No. of drives proposed 

5 




No of frames.proposed 

1 




No of Fibre Channel ports 
proposed with this library 

2 




No of Media slots proposed 
in the library 

50 



4 

Protocol Supported 






FC 

YES / NO 




FCP . 

YES/NO. 




FC-AL 

YES /NO 


5 

Power Supply 





Hot Swappable Power 
supply proposed 

YES 

YES / NO 



{N ♦ 1) redundant power 
supply proposed 

YES 

YES / NO 



Dual AC ipput proposed 

YES 

YES / NO 


11 6 t 

Coding Fans 





Hot Swappable Cooling 

Fans proposed 

YES 

YES/NO 



(N*l) redundant Coding 
Fans proposed 

YES 

res / no 


7 

Support for online automatic 
calibration of robotic arm 

YES 

YES / NO 


8 

Support for NDMP for taking 
backup of NAS over LAN 

YES 

YES / NO 


9 

Support for multiple hosts 
running OS including AIX, HP- 
UX. Linux. Solaris. Windows 

YES 

YES/NO 


10 j 

Support 










► 

£ X 
fc-■«« 
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Tape Library 


Arttiexure Vl.b.5 


Parameter 


Minimum 

ftequlrementa 


Unit of 

Measurement 


Please mention deviations, If 
any 


r\ 


Is the proposed 
product/solution End-of-life 
or will reach End-of-life 
within 24 months from the 
date of submission of bid or 
12 months from the date of 
I acceptance, whichever is 

later? 

1,1 * * •' •** - • • - I, i 

Will the proposed 
product/solutioo reach End- 
of-support during the 
, currency of contr act? 

Jl. Mgjk A A^soriea " 

No. of tape media proposed 

- 1 — 1 ■ ■ » *-* ■■ ■ -— . 

Size of tape media 

(uncompressed) 

Size of tape media * • 

(compressed) 

—- — i, ...i it. . . .. ^ 

No of tape labels proposed 
12 Provisioning of Bar-Code 

Reader within the Tape Library 
& integration with proposed 
Media Management Software 


YES / NO 


NO 

YES / NO 


Hours 

2500 

Units 

800GB 

Units 

1600GB 

Units 

2500 

Units 

YES 



# 
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Load Balancer 


Annexure VLb.6 


Power Specification 


Indian power |0,v,Hz 

specification* in terms of 
Phase, Voltage, Frag 


[Operating Relative Humidity 
(non-Gondensfj 

- -f, ti __ 

Should be a multi processor 

based appliance 

L - *-*'• ■* : -->■ - ,-| « , 

input 


Network Connectivity support 4 x KVlOQ/1000, iGbps 

connectivity 


on the device 


U^oncu^cwnectioos 


1 6GB 
1 Minion 


jJ concum^ cohne^ttons 
[Should suport L7 connections 
second 

ImAii (i il fi r t T1 r - r i 

Should support minimum L7 4 Gbps 


250P00 

, ii L iin ir 

35000 


Mr-•: -.vat!, dog 



Should support SSL offloading 
& HTTP acceleration from day 
one in same unit without 
adding another hardware to 
save rack space, power & 
cooling requirements 

Yes 



;SSLJhrooghftfr' 

2 Gbps 



Initial TPS support 

. . 35000 


Mabt TPS support 

5Q000 1 


Hardware Compression 

Support 

6 - 8 Gbps .. . ... 


NAT entries 

" ,>1 n ‘ " * " 111 ^ ‘ Ti 1 * 
i_... .. 60006! 


Concurrent SSL connections 

1.00.006+ 



Virtual Local area Network 
(Mans) 

512 



Virtual servers 

3000 



Server farms 1 

. . 2500 



Real servers 

. .eooof.. 1 


Support for stlckey table 
entries 

106000 



Should support Port 

Aggregation IEEE 802.3ad 

Yes 

1 


Should support Vlan Trunk 
|EEE 802.10 

Yes 



Should have minimum t Gb 

Flash Drive 

Yes 



Should support Port Mirroring ' 

/es 

* 


Should support following 
deployments 

fes 


1 

1 

% 

< 

touting Mode: where client- > 
iide and server-side VLANs 
>re on different subnets 

fes 


s 

2 

Jrkfge Mode: where client- \ 

;ide and server-side VLANs 
ire on the same subnets 

— W ■ 1 ■ - T 1 II . 4 

f es 



*Jr 1 ? I ‘ ^ t 1 ** < 





m 

e 

% 


* 


Vi 




r+ 

* t 


i 4 

4 I 

r 


c v 


r* 

* f 

r% 

r •» 

t * 

# 

i^’l 


t 

v,. 


r~i 




c# 

J-" A 

«*-- — 




V* 

< 


o 
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9 



9 

♦ 

9 








9 ^ 



9 

9 


9 

9 



Load Balancer 


Annexure VLb.6 




Sr. N6 


Parameter 


Minimum Requirement 


Unit of 

Measurement 


Direct Server Response 
where SLB load balance an 
initial request from the client to 
a real server; however, the 
server directly responds to the 
client bypassing the SLB. 


Yes 


Server load balancing based 
on SNMP parameter like CPU 
load. Memory utilization etc 
Should support Client NAT & 
Server NAT and PAT and NAT 
pool for Dynamic NAT 

In case of Server/Application 
failure device should detect it in 
not more than 30 seconds 


Yes 


Yes 


n I . «■ ... 'l l r l V 

In case of Server failure traffic [Yes 
should be diverted to another 
Server automatically 


Should support following 
content based Load balancing 
features 

1 ** ** "» '*'* a '• i 

Support for protocols namely 
HTTP. FTP. DNS. Internet 
Control Message Protocol 
{ICMP), Session Initiation 
Protocol (SIP). ReaFTime 
Streaming Protocol (RTSP). 
Extended RTSP. RADIUS, and 
Microsoft Remote Desktop 
Protocol (RDP). 


Yes 


Yes 


| HTTP Header based 


Yes 


[redirection 

■-**-■ -** ..I i 


! Should Support HTTP Header |Yes 
manupulation on Client 
requests and server responses 


UR Leased Red irection 


Yes 


Browser Type Based }Yes 

Redirection 

****^A*i ir n N1 til _ _ 

Preferential Treatment (Cookie-| Yes 
Based) 

^ — »■ *i _ 

Should support End-to-End [yes 

SSL Encryption (Backend 
Encryption) 

•».,«! llMin ■1,1 li 


Shoukf suppori SSL initiation ( (Yes 
SSL between SLB 3» Servers) 


IPredictprs 



i 

i 


♦ 



^>6<9 


'•'S 


A 


^ ' 1 . 


* 
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Load Balancer 


Annexure Vl.b.6 


* 


iSS.i 


sr.ifc 


* < 




I r' 

Parameter 




tVH 






r $3&LV4i j? i 




toad Balancing algorithm 
should support following 
algorithm namely Least loaded, 
| Round- robin .Adaptive 
| response,least 
bandwidth. Least 
connect ions,Hash 
address.Hash cookie.Hash 
header,Hash URL 


|Yes 


Probe Support should be 
available for the protocols 
HTTP, HTTPS, SMTP, POP3. 
IMAP, RADIUS, SIP. RTSP, 
SNMP. Telnet, FTP.KAL-AP, 
ICMP. TCP, UDP, Echo, 
Finger, DNS 


Yes 


[Support for scripted probes. Yes 


Server Management Features 


Should support Graceful 
shutdown of Servers 

LA-V. ..»■ ... 


Yes 


Should support Graceful 
Activation of S erv ers 


Yes 


Should able to redirect traffic 
based on Source IP, 
Destination IP & TCP PORT 


Yes 


Virtualization 


The Load Balancer should 
support virtualization or 
segmentation where it should 
be possible lo create virtual 
partitions from day one. Each 
of this Partition should be 
completely isolated from each 
other wrt dedicated access 
control and resource allocation 


Yes 


Should support Min & Max 
| resource allocation per virtual 

! Partition 

• » .... 

Should support resource 
sharing between virtual 
Partitions so in case if 
resource is available with 
another virtual partition it can 
be borrowed automatically 


Yes 










¥ 








o # 

j. 

c> 

<f 

cf 

{P 

yj 

a 

o 

o# 


o 



■ 1 


?. f!rxr.wnti, oug 


.* ! 


• •. »«. 


• '* . i, .i 


*,n ‘ A - 


• t' 


i i 


Should keep configuration files {Yes 
separately for each virtual 
partition or segment 

•« ■ fc/ ■ -i—. ■ ... 

Health Mohitorin< 

- -.. r~ — 7 ii - 

Should provide individual (Yes 

I health checks for real servers 
& farms 

* * u i > i i i m i n' 

Should allow to monitor |ves 

protocol like HTTP, SMTP. 

POP. FTP etc 


. rT '• • 


I. » 
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Annexure Vl.b.6 


Load Balancer 


A 


• ^ 


|g| 


e 

# 


% 

* 

# 

m 



LL 


, * J ' 

.<» 5 r 4 

Wife? 

’/f'VWl; 

wiinSA-- 

■V* *’ ^ ’ 

r ;f' n ' * i 

' Parameter;; 

#?■ ' v?.* -W «ff y ik? 

vV- ft 5 

,MlirnumR6cji4^nV%ni 

tfragSfef *!*$ 

4 

« / 1 1 | 

' ' / 

V , V 1 -s' 

^ 1 * 

Ykf.ki.^. a: -J. * Jh 

% K * ‘ 'M&i'#*, * 

, ter* ' r» > • .. . . 


Should allow to configure 
Customize health probes 
based on TCP & UDP 
parameters 

Yes 



Should provide GUI to 
configure Health Monitoring 

Yes 



Should provide flexible Script 
based support for complex 
environments A advance health 

Yes 





monitoring 

- 


_ f A- * _-_»_ 

1 

7 

Redundancy 




System and Session 
redundancy-failover should 
happen automatically, with no 
human intervention,Should 
Provide stateful failover 
capabilities 

Yes 



Should support Redundancy 
protocol like VRRP 

Yes 



Should support transparent 
failover between 2 devices 

Yes 



Should support transparent 
failover between 2 Virtual 
Instances configured on 2 
different units 

Yes 

• 


■ 

Should Supports active* 
standby and active-active 
redundancy topologies with 
automatic configuration 
synchronization 

Yes 

1 ■ - - -_^ _ _ L _ . * * 



The failover should be 

Yes 





transparent to other networking 
devices 





8 

Security 




Support for Access Hi 

100 Q-> 

-< ‘ -^ -J i I l 



Should support HTTP deep 
packet inspection (HTTP 
header, URL, and payload) 

Yes 


- 



Should support bidirectional 
Network Address Translation 
(NAT) and Port Address 
Translation (PAT) 

Yes 


• 


b 

Should support TCP 
Normalization & TCP 
connection state tracking 

Yes 


J 

Should support ICMP flood 
guard 

fes 



Should support Virtual 
connection state for UDP 

Yes 


• 

>« 

Should support Sequence " 

lumber randomization 

Ye s 



Should support TCP header > 
validation 

fes 


* 

4 

* 

U 

Should support TCP window 'i 
jize checking 

fes 




( 

\ 

a 

% 

Should able to detect & drop > 
»ame Source port & 

fes 



# 1 

00 

• ' i - 

Jestination port traffic 

.— 4— fc. I .1 „Ju 







a ♦ 


^)0 
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j 


1 «V I I 
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Load Balancer 


Annexure VLb.6 


i* ; :-4 f i 

■‘Kj * 


Sr. Mm 


I 'V/ 

-'Jv r- ft 
& \'u 

ft - 


Parameter 


« / 
njWfc/ 
> >y 

T V 


Mtobrtuin RequlnwriSrt 


10 


11 


j Should able to detect & drop 
L4 port 0 traffic 

«... . i. .,._ 

Application Acceleration 


r»« 


[Yes 


r 

1 ♦ 


Should Support SSL 
Offloading & Acceleration on 
same hardware to reduce 
number of equipment in Oata 
center & save power / cooling 
requirement 


Yes 


At 




• (O' 


-5*K 




* V? 


IT* 




65001 


support for TPS 
[Should support HTTP 
Compression technologies like 
GZIP & DEFLATE using 
dedicated hardware chips 

JU '*~ *■*•'*“ r in rt 

Should use dedicated 
Hardware Card / Module for 
compression & not software 
based compression 

Should support dynamic 
caching technologies 


7500 


I Yes 


[Yes 


Yes 


Should store cached content in ]Yes' 
[ RAM for faster content delivery 

. * *“ "**■' Ml - J - 

Should support transparent |Yes 

TCP Multiplexing (TCP 
Offloading) 

■■—■ - 1 -• i n 

Management 

pw wii n«^n r m ObyiLUM 

Role Based administration |Yes 

support namely Admin.Security 
adrmn. Network-Engineer, 

Network Monitor. Network 
Manager 

Telnet lY*** 

Hh -g 

Yes 
Yes 


HTTPS _ 

RS232 -Console Port 


Yes 

- 

Yes 


NO 


SNMP 

—« ‘ - ■ n 

Should support GUI for 
configura tion & monitoring 
Sui 

Mat 9 i _ j_ 

Is the proposed 
j product/solution End-oMife or 
will reach End-oMjfe within 24 
months from the date of 
submission of bid or 12 
months from the date of 
acceptance, whichever is lateral 


Will the proposed |NO 

product/solution reach Ertd-of- 
support during the currency of 
contract? 


■. • * »11. 


4 






t m. 

V_3 
* j 

J 

4 


s. > 


£ * 
* 


4 

¥ 


V-~-i 


.7’ 


£ >. 




44 




r* > 


r \ 


o 


It- 


G 

O 






n 

'<4fc- r 


0 
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Terminal Server 


Appendix Vl.b.7 



0 

0 

0 

0 




0 

0 

0 

0 




Sr. No 

Parameter 

Minimum 

Raetu^niwnt 

Unit of Measurement 

1 

Power Specification 

Indian power 
specifications in 
terms of Phase, 
Voltage, Freq 

0,V.Hz I 

2 

Network 




No ofasynchrnonous ports 

24 

number | 


WAN Interfaces 

Seria/BRWW 

DtalvP<xD$L 

YES / NO 1 


Auxiliary and Console ports 

YES 

YES/NO j 

3 

Support 




Is the proposed product/solution 
End-of-life or will reach Ehd-of- 
tife within 24 months from the date 
of submission of bid or 12 months 
from the date of acceptance, 
whichever is later? 

NO 

YES/NO 1 

— 

Will the proposed product/solution 
*each End-of-sup port during the 
currency of contract? 

NO 

YES/NO 

4 

1 

! 

! 

Remote Management 

, 

, 

• 

Hardware 

based. 

Operating 

System 

independent 

Remote 

Management 

having 

Integrated 

Management 

Log, Support for 
multiple user 
accounts with 

customizable 

access 
privileges with 
SSL level 
security, SNMP. 

YES / NO 





0 

0 

0 

0 

0 






0^ )<& 
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V, J 


Appendix Vl.b.8 

Technical Specifications for Firewall -Dedup-DB Firewall 


Jill 


1 — iicrim if ~r •iHuim. m i r_ 


1 

Pcwer Specification 

Indian power specifications in 
terms of Phase, Voltage and 
Frequency 

0,V,Hz 

2 

Architecture 

The appliance a multiprocessing 
system Architecture for high 
performance 




Yes 

YES/NO I 


System should support Firewall, 
IPSec. VPN. SSL VPN. Unlimited 
users/nodes 

Yes 

YES/NO I 

3 

Mj^AvailabtHty Features _ 



• 

Capability to detect hardware failure 
duing powertip and before going 
online 

Yes 

YES/NO I 


stateful failover to prevent session 
losses to minimal Firewall support 
rack serviceability with easy access 
mainboard 

y£- 

YES/NO I 


Software reconfiguration/ 
configuration changes are immediate 
effect 

Yes 

YES/NO I 


Support active/active and 
active/standby failover 

Yes 

YES/NO j 


Should support VPN Clustering and 
Loadbalancing 

Yes “ ' 

YES/NO j 

^ ,i ii* 

Support m-buift environmental 
monitoring capabilities. 

Yes 

YES/NO 

4 

Concurrent Sessions 

at least 1500000 and at least 
80000 sessions per second 


5 

system.Throughput 

5Gbps and higher 

3 bps I 

6 

7 

Memory i 

I 

* 

< 

c 

II 

at least DRAM - 5GB or 
higher 

* least Flash Memory 1 GB- 
x higher or any other storage 
f required 

58 | 


8 


Expansion option 


9 Application and protocol inspection 


ports arid expandable 
minimum $ Nos of lOCbps 
Ports and expandable 


Network interfaces like Fast 
| Ethernet/Gig Ethernet /1 OG 
Ethernet modules 

4* ... ». 

Should integrate with more 
than 24 specified inspection 
engines for protocols such as: 
(but not Kmited) 

“ * - k » . ii 

Advanced Web Browsing 
[HTTP) 

Fite Transfers <FtP) 


units 


■units 


YES/NO 


' Electronic mail JYES/NO 

(SMTPyeSMTP 

< "i > ‘ , , I II ^ 

I Domain Name System (ONS) lYES/NO 


C.S. Nannwati, dog 

t • i 'MrOU." r n Amftu;?;*/ of * 
~ i W'*-; Conirni^sv'ii Biv-H'ilr, 

C cnn t ;t;uh \ Circus f>:-*v Delhi ' V')[; i 


o 


r\ 





Q 
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+ 

# 




Appehdix Vl.b.8 

Technical Specifications for Firewall -Dedup-OB Firewall 


Support VPN 


11 


Authentication, Authorization and 
Accounting (AAA) support 


Other 


% 

* 

V - ' 

* 


/ 


K ? » -“x i i *■ 


i • ( I l « • L * L ( 


i H** 


f fi s \*r * g f . !. 1 1 / ; 




i > 


1 Simple Network Management 
Protocol (SNMP) 

YES/NO I 

1 Database (SQL'Net) 

YES/NO | 

1 Network Fite System (NFS) 

YES/Np | 

|lP Jelephonu - H.323.SIP 

YES/NO S 

VoIP 

YES/NO I 

1 Session Initiation Protocol 
|(SIP) 

YES/NO j 

| Real-Time Streaming Protocol 
(RTSP) 

| e 

YES/NO 

j Internet Locator Service (IIS) 

YES/NO j 

I Provider voice services 
| (MGCP.GTP/GPRS) 

YES/NO j 

1 Network Information services 
(NIS+) 

YES/NO j 

1 Stateful ICMP inspection 

YES/NO.j 

(IPv6 transparent 

YES/NO 

[Timebound, Out bound ACLs 

YES/NO j 

1 Inspection engine should 
[support an interface,network 
lor host 

YES/NO I 

[Tunneled applications (peer-to 
[peer file sharing or instant 
[messaging) 

YES/NO I 

JSupports. 


[ike 1 

YE$/NO ] 

| IPSec VPN standards 

YES/NP 1 

iPPTP * 

YES/NP I 

156-bft DES 

YE'S/NO | 

|168-bit 3DES 

YES/NO I 

[OSPF routing and QOS over . 
iVPN 

YES/NO 

|piffie Heilman Group 7 

YES/NP | 

1x509 

YES/NO J 



j Up to 25S*bit AES data 
(encryption 

YES/NP 

integrates with popular AAA 
[services via 

YES/NO I 

(radius 

YES/Np I 

[TACACS+ > 

YES/NP | 

[Acountmg for management s 
(traffic 

YES/NP 1 

1 Native Active Directory user > 
authentication(VPN only) 

f ES/NO | 

[Native SecurelD V 

1 authentication (VPN only) 

'ES/NO I 

[Support for 


j Port redirection and TCP V 

[intercept 

ES/NO 1 

|R^ck Mountable y 

ES/NO 1 

(ActiveX blocking y 

ES/NO | 

m I 

| URL filtenng and Java Y 

(Security 

ES/NO | / i 






\ \ 9t 


V 


N *v? ” <v 
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13 


14 


15 






It* * M II 




Support against all network [YES/NO 
and application level attacks 
ranging from malformed 
packet attacks to DoS attacks 






Support for ability to I YES/NO 

customize protocol port 
numbers 






Support upto 1536 bit RSA [YES/NO 
and Diffie-Hellman, MD- 
5.SHA-1 


■~n i I.«ii. 


DHCP relay 


Forwards DHCP requests 
from internal devices to an 
administrator-specified DHCP 
server, enabling centralized 
distrkution, tracking, and 
maintenance of IP addresses 


YES/NO 




Provides: 

>41 f ■ l a *. 




YgS/NQ 


Rich dynamic NAT and PAT I YES/NO 


services 


— ■* 


U*. 


> , * 


Static NAT and PAT services YES/NO 


M ■>*! 


idfrl.lll Hilt 


-A_Liu_* 


Policy-based NAT and PAT [YES/NO 
services 


.. ___ * f l *' >* * III HI ^-1— .... ■ ^ .J-— *- .. . .. 

X-509 certificate andCRLsupport Supports SimpleCertfflcate|YES/NO 

Enrollment Protocol (SCEP)- 
based enrollment with leading 
X.509 solutions from 
Baltimore. Entrust, Microsoft, 
and VenSign 




Management 










Web based management to [YES/NO 
support for remote monitoring 


h*,,Ai tow. 




- *-• • - ■ | 


Accessible through variety of | Y E S/NO 
methods including ; Telrtet, 

Console Port.SSH 

- k ~'— - - - - j »-•- v -f- . . ♦ A „ 




Dedicated Out-of-Managenet IYES/NO 




[interface 


| Support SNMPvt, v2, v3 


n >IM UM 

[YES/NO 


Support for security event I YES/NO 
logging 




Support real time alerting and [YES/NO 
notrfication features and 
syslog 

- nM t ts-i »t t fit „ . <t .. ifV„ ll . H , i .ii U n i. ir 

Should have the ability to [YES/NO 
create customizable 
administrative roles/profiles 
(monitoring only, read-only 

accets .to nSnflrn \/P*J 




1*1 I * tutu 






wv- #, 


ffl 


w 

1 i 


« ■» 


I 

T 


.4^ 

5 


C: 


c 
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&0 
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^ t ^ * f" * | 
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16 


17 


18 


19 


20 




21 


22 


23 


m... 


i.. ju.A 




~ i ~ 


End point verification 


" 1 r 




Support for end point 
authorization based on 
multiple variables of each 
VPN connection associated 
with specific tunnel or session 


YES/NO 


* dii. 




Software features 


ii 


»<«> ««n «\i 


support for RIPv2. 
OSPF.VLAN, LAN Based 
failover, DHCP Support, 
static^ Dynamic NAT/PAT 
Support H.323,SIP,FTP,etc 
Bididional NAT, NAT 
trasparency, Split tunneling 
VPN, 


YES/NO 


Software 




Latest release with all 
supported features as 
required 


I I Oi II fc I in I I, maJemlmu 


Broadcast Application 






I YE S/NO 


Support for Microsoft 
Networking client server 
communication 

support for muftimedfa Real | YES/NO 
Audio Video Stream Works, 

Applications based on H.323 
standards 

*• -^*-*-* ) * * k -* -»^ 


Support for Oracle SOL and |YES/NO 
ERP applications 




n 


i 1^ t ■ i ,1 


Client VPN 


— |V. rf.i 


4 ■ < ii . ■*— 'if, i ill 




1 ' i . i t I n *. ■!.. 

■a.. * - ,Jt * * ‘ ■ - t -'—«■—-• * I i *4~ * m u In ■flii.... rill_f_•_ 


support and not limited to | YE S/NO 

Internal websites/web enabled 
applications. 




Email- |YES/NO 

POPSS.IMAP4S.SMTPS. 




* i ■ - ttm4k - « d • -> ■ -» "■ 


■A.-.M U. ... ■ ’ n. i ii, ,i iJ 




Support also telnet,RDP,VNC.|YES/NO 
MAP! and Application Access 
support 

* I, 


Mounting 




Standard 19-in rack with 
required hardware 

>:■><*** V Ii if,,*. In, 1 


- r » • *- — -p ^ 


YES/NO 


Cbmpatability with proposed networkjYes 
devices 


-*■ - ■* 


t > hi fcfcji .imMmWwmW 


- **■ - I- . r ,|-|' l | 


Compatability with proposed network {Yes 

security devices 

' f - - » lj -* -- - 


[YES/NO 

M-fri 


M >* , i 11, 


YES/NO 

-* 1 ' i 


I 


. ‘ 1 > 


1 1 


l *- 


.it 


r . 


• i * 

*« L ' 
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25 

Compatability with proposed servers 

- - ii, , -—..... 

Yes 

YES/NO 

26 

Power Supply 




Hot Swappable Power supply 
proposed 

Yes 

yes; no 


(N+1) redundant power supply 
proposed 

Yes 

«* . 

YES / NO 


Dual AC input proposed 

Yes 

YES/NO 

27 

pooling Fans 




Hot Swappable Cooling Fans 

Yes 

YES/NO 


proposed 


28 

(N+1) redundant Cooling Fans 
proposed 

SUDDOrt 

Yes 

YES/NO 


Is the proposed product/solutioft End- 
of-life or will reach End-oMife within 
24 months from the date of 
submission of bid or 12 months from 
the date of acceptance, whichever is 
later? 

NO 

• 


» 

Will the proposed product/solution 
reach End-of-support during the 
currency of contract? 

NO 



Will the proposed product/solution 
reach End-of-support during the 
currency of contract? 

• r --.• -. 

NO 







i 








$ 
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Web Server 


# 

Sr. No 

Parameter/ Features 

Minimum 
. Requirements 

UrUtof 

Measurement 

1 

Protocols Supported 

http(s) 

YES/NO 


2 

Security & Authentication 


---*---- -■ 

• 


Client Authentication 

Userid/Passoword, 
PKI (digital 
certificates) 


# 

3 

Support 



• 

V 

A 


Is the proposed product/solution 
End-of-life or will reach Ertd-of-life 
within 24 months from the date of 
submission of bid or 12 months 
from tjtte date of acceptance, 
whichever is later'? 

NO 

_ 

YES/NO 

W 

* 

• 


Provide new version upgrades, 
updates, patches, etc for all the 
components / sub-components 
through the period of contract 

YES 

YES/NO 

e 1 

L 


Will the proposed product/solution 
reach End-of-support during the 
currency of contract? 

NO 

YES/NO 

—---—— 








0 


m 





J 






Bid No. D-11018/14/Tech/10-UID AI 


Anhexure F - Minimum Requirements and Technical Particulars 


— -m 



Fire Resistant Cabinets 


Appendix Vl.b.10 


mm 

*nm 

S- -— 

Parameter 

*ef* . 

v, Ntolmtifr? 


7 

Interior Temperature range 

50 °C 

®c 

8 

Interior Relative Humidity range 
(non-condensing) 

80% 

% 

12 

Maximum Temperature 
sustainable at the required 
interior Temperature and 
humidity 

1000°C 

°c 

13 

Maximum exposure time to fire 

1 hour 

hours 

14 

Comply to Class UL-125 -1 
hour specifications 

YES 

YES/NO 

15 

•. . J 

Manufacturer of cabinets is 

ISO 900V2000 certified 

YES 

YES/NO 

16 

Warranty for period of contract 

YES 

YES/NO 



a* 
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Virtualization Server Software 



Parameter/ Features 

Minimum 

F^epuirwrifente* 


1 

Support 




Is the proposed product/solution 
End-of-life or will reach End-of-life 
within 24 months from the date of 
submission of bid or 12 months from 
the date of acceptance, whichever is 
later? 

NO 

YES/NO 


Provide new version upgrades, 
updates, patches, etc for aB the 
components / sub-components 
through the penod of contract 

YES 

YES/NO 


Will the proposed product/solution 
reach Ertd-of-support during the 
currency of contract? 

NO 

a 

YES/NO 

_ _ 












a!*?o 
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Virtualization Server Manager Software 


Sr. Mo 



k-- 

1 

General management 




Performance monitoring capabilities 
includes resource utilization (CPU 
utilization, memory, disk I/O, and 
network I/O) for a host server and 
virtual machine 

YES 

YES/NO 

• 


Maintain version and inventory of 
virtual machines 

YES 

YES/NO 


Automated deployment of VMs, OS 
batches and applications 

YES 

YES/NO 

-W 1 . . * b - - ♦ . * V 

2 

r - 

1 

Support 



Is the proposed product/solution 
End-of-llfe or will reach End-of- 
* life within 24 months from the date 
of submission of bd or 12 months 
from the date of acceptance, 
whichever is later? 

NO 

YES/NO 

Provide new version upgrades, 
updates, patches, etc. for all the 
components / sub-components 
through the period of contract 

YES 

YES/NO 

Will the proposed product/solution 
reach End-of-support during the 
currency of contract? 

NO 

YES/NO 





V 
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Backup Software 
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• 

# 




# 

# 

# 

% 

* 


t h * 

v < r 

st.ml 

C"? 

* r . ,u 

>/ Parameter/ Features 

* 

Minimum 

Requirements 

Unko# 

Measurement 

Please mention deviations, if I 
any j 

1 

Should have capability to 
support for all major Operating 
system clients including. but 
not limited to AfX, HP-UX, 
Solaris, Microsoft Windows. 
Linux, etc 

YES 

YES/NO 

• 

* 

i 


2 

Support for heterogeneous 
storage solutions including 
EMC, Hitachi, HP, IBM, 
Network Appliance. Sun, etc. 

YES 

YES/NO 


3 

Should be flexible and 
configurable to adapt to 
organization's backup policy 

YES 

YES/NO 


4 

Should have capability to 
generate scripts 

YES 

YES/NO 


5 

Should have support for 
Development kits / API for 
customization of scripts 


YES/NO 


6 

Capability to configure 
automated backups with 
customized frequency based 
scheduling based on the 
backup policy. 

YES 

• 

« 

YES/NO 


7 

Full fledged Media Library 
Management, including • 
complete and automated offsite 
tape management, creation d 
pickup and drop lists, tracking 
of tapes, etc. 

YES 

YES / NO 


8 

Should be configurable for 
incremental backups or full- 
backup of the applcations. 
database, files, etc 

YES 

YES / NO 


9 

Capability to leverage Storage 
Area Networks (SAN), Network 
Attached Storage (NAS) and 
Gigabit Ethernet for backup 
and recovery 

YES 

YES / NO j 


10 

Should leverage provisioning of 
Business Copy by various 
storage vendors for zero- 
downtime backup. 

YES 

fES / NO 1 


11 

Rich GUI with single screen 
monitoring for complete 
backup / restore activities 

YES >i 

rES/NO J 


12 

1 

Capability to retrieve selectively 
based on search criteria 

'i 

'ES/NO 


13 ( 

< 

X: 

« 

r ~ • »'*' f 

{ t V - w 

\ . .; 

Capability to backup the entire > 
configuration of the server and 
estore t from scratch the 
intire system including 
configuration when in a 

5cerja(ip of hardware failure 

• r ' i f < ' 

YES > 

'ES / NO I 

Af/TVS 

Uf A —Ky 

/ +1 s j j \ \ 

| ^ * i I 


z> 


W L 


. | * e » * t ' 

; i * * /v l * - • * 1 ' ’ 
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Backup Software 


Appendix Vl.c.3 


Sr.N6 

✓ v ‘' 
y 

> c 

V 

Parameter* Features 

< 

< f y <«, 

MtMNlM 

>*4 

p- rffe 

V- • “rv- 

Mv&mtrmz 

1 V*' * 

pimm 

"V ^ '{Sgf ™ J 

14 

Time required for the 
restoration of the configuration 
on to the server 


Minutes 


15 

Capability to reed and write 
multiple streams 
simultaneously to i from one or 
more tapes and from more 
than one diento/servers 

YES 

YES/NO 


16 

Should aBow for a failed 
backup or recovery job to be 
resumed from the point of 
failure rather than restarting the 
job alt over again. 

YES 

YES/NO 


17 

Should allow for a failed 
backup or recovery job to be 
resumed from the point of 
Mure rather than restarting the 
job aB over agatn. 

YES 

YES/NO 

• 1 

18 

• 

Should be configurable for 
usage of network bandwidth it 
should provide the 
administrator the capability to 
throttle and restrict bandwidth 
usage on LAN. 

YES 

YES/NO 


19 

Capability to integrate with the 
EPM proposed 

YES 

YES/NO 


20 

Support. . _ 




Is the proposed 
product/solution End-of-life 
or will reach End-of4ife 
within 24 months from the 
date of submission of bid or 
12 months from the date of 
acceptance, whichever is 
later? 

NO 

YES/NO 


Provide new version 
upgrades, updates, patches, 
etc. for all the components / 
sub-components through 
the period of contract 

YES 

YES/NO 



Will the proposed 
product/s olulion reach End- 
of-support during the 
currency of contract? 

NO 

• 

YES/NO 










' ^4 
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Replication Software 


Sr. No 



Parameter^ Features 



Onkof M«&urtfn*nt 


Support 

. . . . _ . a k ■ u . i 


Is the proposed NO 

product/solution End-of-fife or 
win reach End-of-life within 24 
months from the date of 
submission of bid or 12 
months from the date of 
acceptance, whichever is 
later 7 


Provide new version upgrades, YES 
updates, patches, etc for all 
the components / sub¬ 
components through the period 
of contract 









I 
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Anti-Virus Software 


J _ L 


: 

1 ,. N '*'t % 

v > * % ¥ •» * > 

i Parameter/ Featured 

- . M Wmtmr, , 

J&fc .Unitor 

1 

Product Name 

McAfee / Symantec 
T rend Micro/Otber 


2 

Version 

Enterprise Edition 


Licenses for components that are prices and sold separately should be indicated as 


Other 2 


' 

3 

Protection for Desktop / 
Servers 

YES 

YES/NO 

4 

Security for SMTP 

YES 

YES/NO 

5 

Security for Microsoft 
Exchange/Lotus Domino 

YES 

YES/NO 

6 

■■ .. 

Security for Lotus Domino 

YES 

YES / NO 

7 

Gateway Antivirus 

YES 

YES/NO 

8 

Support 




Is the proposed 
product/solution End- 
of-tife or will reach End 
oMife within 24 
months from the date of 
submission of bid or 12 
months from the date of 
acceptance, whichever 
is later? 

NO 

YES/NO 

• 

Provide new version 
upgrades, updates, 
patches, etc for all the 
components / sub¬ 
components through 
the period of contract 

YES 

YES / NO 


Will the proposed 
product/solution reach 
End-of-supporl during 
the currency of 
contract? 

NO 

res /no 







* 

» 

# 
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+ 



+ 

# 

# 

# 

* 




* 


+ 

* 

m 



$r.;m 

t & '* iV ’t 

Parameter# Features t< -w 

, t * 1 . \ i r , 



Licenses for components that are prices and soW separately should be indicated as 

1 

No. of Licenses (Primary Site) 


—.-.— ‘-■»' ' -. 


Client 

For all servers and 
devices 


2 

Capable o( receiving messages via 
UDP. TCP or SNMP 

YES 

YES / NO 

3 

Capable of forwarding messages via 
UDP or TCP 

YES 

YES/HO 

4 

Capable of sending SNMP traps 

YES 

YES /NO 

5 

Buffer for 20000 Syslog messages to 
ensure too toss of messages under 
heavy load. 

YES 

YES / NO 

6 

Support RFC3164 send and receive 
options 

YES 

* • 

YES /HO 

* 

7 

Pass values from the received Syslog 
message to an external program, e- 
mail message or Syslog message 

YES 

YES/NO 

8 

Support 



is the proposed product/solutiort 
End-of-life or will reach End-of~fife 
within 24 months from the date of 
submission of bid or 12 months 
from the date of acceptance, 
whichever is later? 

NO 

i 

YES/NO 

Provide new version upgrades, 
updates, patches, etc. for all the 
components / subcomponents 
through the period Of contract 

YES 

YES/NO 

Will the proposed product/solution 
reach End-of-support during the 
currency of contract? 

NO 

YES / NO 


# 

# 

* 

* 

4 
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Cluster File System 


Sr. No 

Parameter/ Features 

Minimum 

Requirement* 

Ufttt of Measurement 

'wA 1 

1 

Should be certified by db 
vendors for operation in 
active-active, active-standby 
mode 

YES 

YES / NO - list 
support/constraints if 
any with the databases 
Oracle. MySQL, MS 
SOL.DB2 

2 

Should also have capabifry 
to run the database on raw 
file system if required. 

YES 

YES/NO 

3 

Journaled File System 

YES 

YES/NO 

4 

Capability for online resizing, 
online backups and online 
defragmentation 

YES 

. . . .* , . 

YES/NO 

5 

—_ _ . _ __ 

Support 



is the proposed 
produet/soluhoh End-of- 
life or win reach End-of- 
life wtthin 24 months from 
the date of submission of 
bid or 12 months from the 
date of acceptance 
whichever is later? 

NO 

YES / NO 

Provide new version 
upgrades, updates, 
patches, etc. for aft the 
components / sub¬ 
components through the 
period of contract 

YES 

YES / NO 

Will the proposed 
product/solution reach 
End-of-support during 
the currency of contract? 

NO 

YES/NO 
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m 

m 

» 



Sr. No 

Parameter/ Features 

Minimum 

Requirements 

Unit of Measurement 1 

1 

Should provide a GUI based 
software 

YES 

YES / NO ] 

2 

Should be integrated with the 
proposed ERM solution to offer a 
single window for monitoring. 

YES 

YES / NO j 

3 

Capabilities and visibility to 
capture status of entire Storage 
Area Network 

Objects Example.Fabric Switches, 
Storage etc . 

YES 

YES / NO I 

4 

Should have capability for 
automated monitoring and 
notification of changes in the 
fabric 

YES 

YES/NO ~ I 

5 

Enable dynamic discovery and 
control of all SAN components. 

YES 

YES/NO I 

6 

Capability for Fabric, switch and 
port naming and enable 
assignment of specific names to 
SAN objects. 

YES 

YES / NO 1 

7 

Capability for change 
management so as to tracks 
changes to fabric objects. 

YES 

YES / NO I 

8 

Capability for traffic prioritization . 
from Hosts at FC port level. 

YES 

YES / NO 

9 

Should allow administrators to 
capture configuration of switch, 
backup the same and compare it 
to current switch configurations 

YES 

YES/NO I 

10 

Should undertake end-to-end 
Performance Monitoring and 
permit early fault detection and 
isolation along with performance 
measurement 

YES 

YES/NO 

11 

Security protection for 
management should make use of 
digital certificates and digital 
signatures, multiple levels of 
password protection, strong 
password encryption and PKl- 
based authentication 

YES 

YES/NO I 

12 

Capability for Hardware enforced 
Zoning 

YES 

YES/NO 

Wizards for zone configuration. 
inter-VSAN routing (IVR), 
PortChannels, Fibre Channel over 
IP (FCIP) tunnels, and IP access 
control lists (ACLs) 

Support Zoning / LUN masking, 
port binding, port masking, etc 

YES 

• 

YES/NO j 

Ol 

Support for Detailed Fabric 
configuration example: Port 
Configuration, Supervisor Module 
Upgrade, Hardware replacement 
.Compare switch configurations 
etc 

Yes 


• • — > • i, 

. : 

Support for CLI interface from 

GUJ 

^f r.r ■ ‘ t rsr'x 

Yes 



* ♦ 1 I . 
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Interoperability support with 
different Fabric Switch 
Manufacturer 

No 

i 


Support for Managing more than 
one Fabric Management Instance 

No 



Support for Managing FCOE 
Switches 

No 



Support for .Schedule periodic 
backups of running switch 
configuration 

Yes 

# 

13 

Support for Managing Fabric 
switch alarms. Notifications and 
Events 

Yes 




• 



Support for reporting of Storage 
Area Network on Inventory. Port 
Utilization, Zone Configuration, 
Trunk Configuration,Performance 
Reports namely. Port Utilization, 
Switch Bandwidth utilization. 
Report on health of the fabric 
switch. Report on License 
Utilization and inventory 

Yes 



is the proposed product/solution 
End-Of-Hfe orwill reach End- 

of-life within 24 months from 
the date of submission of bid or 12 
months from the date of 
acceptance, whichever is later? 

NO 

YES / NO 


Provide new version upgrades, 
updates, patches, etc. for all the 
components / sub-components 
through the period of contract 

YES 

YES/NO 

_ 

Wilt the proposed product/solution 
reach End-of-SUppOrt during 
the currency of contract? 

NO 

YES/NO 





** %» 





✓ • 
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Storage Manager 


Sr. No £ Parameter/ Features 

T * ~ - ' 4 ■ -. » 


Minimum Retirements! Unit of Measurement 


1 Should provide a GUI based * (YES 
software , 


YES / NO 


~2 (Should be integrated with the I YES 
proposed ERM solution to offer a 
single window for monitoring. 

■ • - ' - -- - m t Am "<■--«*- 1 

3 Capabilities manage 

heterogeneous storage arrays 
from leading vendors 


YES/NO 


. j.*! ■ *» 

EMC 


YES 


YES / NO 


YES 


YES / NO 


YES 


YES/NO 


Network Appliance 


IYES/NO 


Sun 


4 Should integrate with proposed [YES 
Backup software 


YES/NO 


5 (Policy Management 

i . i' i ml il f -1 - ■ ‘ 


Configuration of parameters YES 


YES/NO 


Volume allocation 


YES 


YES / NO 


Storage reconfiguration 


YES 


|YES / NO 


Cache management 

-k - --» ■>. DM 


YES 


Reallocation of capacity 


YES 


YES/NO 


, ■*-' II —*i ** ■— . 

Monitoring, analyzing, tuning [YES 
performance ‘ . ...... 


Automated customizable policy [YES 
based provisioning / allocation 


[yes / NO 


of storage 

_>l . | I. )l||- ■ ' < ■*! 


6 Addition of new hosts without any [YES 
downtime 


[YES / NO 


yes 


ft r * rt lii i .. H i U ii i4i | H I» >■ I H » I < I n ■ H n !>»!»■ »■ Amum+ m 

7 Fast file system recovery 
a Extent-based allocation of disk to YES 


YES/NO 




YES / NO 




9 Online file de-fragmentation 

- ■ m . in. ^ 1 -i* > m il 

10 Directory optimization 


YES/NO 

.it, I ,1 Sm* i XI t 

YES / NO 


\ 1 Dynamic load balancing with [YES 
functionality for spreading I/O 
between the multiple paths of 
multi-controller disk arrays to 
increase the performance and 
availability 


YES/NO 


12 Automatic path failover and 
dynamic recovery 
^3 Monitor all the paths that are 


YES/NO 
YES / NO 


14 Support periodic auto detection of [YES 
failed path without the need for 
manual detection 


YES/NO 


Ts [Capability to define, configure. I YES 
add. delete, expand, and reassign 
Logical Unit (LUN) to specific 
paths non-destructivefy and 
without having to reboot the 
system 

^ . I tl «. - 1 , , r ^- 1 - ■ ^ •' **- ..* ■**** 1 1 * * 

I 16 Provide various reports for 


YES /NO 


YES 


m~s / no 


management 




# 



} t 


C\'\ Ncnz'.vr.ii, doc 

iv •" ' : :i*ua:r»i, t * ‘ **»» 


1 . jvsi n J* r.vv.n 
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17 

Measure the performance 
statistics of each and every 
component of the storage 
subsystem and should afso 
provide an extensive set of 
graphs 

YES 

YES / NO 

• 

18 

Real time and historical monitoring 
and support threshold based alert 
mechanism 

YES 

YES/NO 

19 

Support 



Is the proposed 
product/solution End-of-lifeor 
will reach End-of-lrfe within 24 
months from the date of 
submission of bid or 12 months 
from the date of acceptance, 
whichever is later? 

NO 

YES/NO 

Provide new version upgrades, 
updates, patches, etc. for all 
the components / sub¬ 
components through the period 
of contract 

YES 

• 

YES / NO 

Will the proposed 
product/solution reach End-of- 
support during the currency of 
contract^ 

NO 

YES/NO 
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Network Management Console Software 

1 ' I* 1, 1 "j ' T . r. 


* A* t 1 ** • K* t/ 

. LI... 



1 

Product Name 

Network Management 
Software 


2 

software 

latest release with all 
software features and 
licenses as requried on 
both server and clients 


3 

... 

Support 




Is the proposed 
product/solution End-of-life 
or wtH reach End-of-life 
within 24 months from the 
date of submission of bid or 
12 months from the date of 
acceptance, whichever is 
later'* 

NO 

YES/NO 

' 1 '* 

Provide new version 
upgrades, updates, 
patches, etc. for afl the 
components / sub¬ 
components through the 
period of contract 

YES 

YES/NO 

- 

Will the proposed 
product/solution reach End- 
of-support during the 
currency of contract? 

NO 

YES/NO 






i 
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n 


Linux Operating System 


1 * *“ » “■ 

Sr. Ntfv 

• ' 

! 4 ; 

r—----- - -*-*-“'t 

4 

\ t 

Parameter! Features 

1 , itA „ 

”* *:* ' * 

; - Unit of 
Mwwur&meM 

m 4. 1 

1 

Product Name 

Red Hat Unux 

- - - * - - 

1 

Version 

RedhatEnt Linux 5.0 
(upgrade 1 or higher) 

• 

3 

No. of Licenses (Primary Srte) 




Max Physical 
CPU/sockets per server 

2 


4 .. | 

Memo*..... 




Max physical memory per 
server 

64 

GB 


Max file system size 
(each) 

10 

TB 

5 

... - 

Support . . .. .. . 



Is the proposed 
product/sotutton End-oMJfe 
or will reach End-of-llfe 
within 24 months from the 
date of submission of bid or 
12 months from the date of 
acceptance, whichever is 
later? 

NO 

» 

YES / NO 

Provide new version 
upgrades, updates, patches, 
etc. for alt the components / 
sub-components through 
the period of contract 

YES 

YES/NO 

Will the proposed 
product/sotution reach Bnd- 
of-support during the 
currency of contract? 

NO 

YES/NO 

. • - ■ . 


* 


—a 
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v 
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Appendix Vl.c.12 

Windows Operating System 


Sr. No 

' - 

.. . rtH 

< N 

* 

# 

Parameter/ Features 

V.'" • ' 

$: 

w * 

"fcfr***---- • 

f t , *» ^' 

* 4 i\ l 

f- 

Mlnhnum> 

' 

W ** * 

- V._^ 

Unit ed * * 
Mwsurvrnan!^ 

1 

Product Name 

windows 


2 

Version 

2003/2008 


3 

No of Licenses (Primary Site) 




Max Physical 
CPU/sockets per server 

2 


4 

Support 



Is the proposed 
product/solution End-of-fife 
or will reach Er>d-oMife 
within 24 months from the 
date of submission of bid or 

12 months from the date of 
acceptance, whichever is 
later? 

NO 

YES/NO 

* 

Provide new version 
upgrades, updates, patches, 
etc for all the components / 
sub-components through 
the period of contract 

YES 

YES/NO 


Will the proposed 
product/solution reach End- 
of-support during the 
currency of contract? 

NO 

YES / NO 
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OS Clustering Software 


Appendix Vl.c.13 



Sn 

N<>: 

. * *Jk 

h' 

«•>-? * - 

» ' 7f ’>r 

*• jm -*< « J?*/' , 2^ r 

’ r */£- pErWheter/iFerturgs 

"i-M - **•*<: 

Rdtpjl 

' 

k k * * & l/'j , . 

J T 


1 

Should be certified by Databases for 
operation in active-active. active-standby 
mode 

YES 

YES ( NO 
databases) 

■2 

Should provide support for running 
multiple Instances of the same 
appAcatkmm the cluster. 

YES 

YES / NO 

3 

Should Support non-intrusive TCP 
cormecdon failover.. 

YES 

YES/NO 

4 

Should ensure cluster members stay in 
sync and communicate their status 
instantly through cluster interconnect. 

YES 

YES/NO 

5 

Should allow simultaneous access to 
sham storage from multiple servers that 
am configured In toad sharing mode. 

YES 

YES / NO 

6 

Should allow pobcy-based. cascading, 
and muto-cfc factional ta^cver 

YES 

YES / NO 

7 

Should be capable d intelftgent workload 
management and should allow 
administrators to set fail-over policies 
based on server capacity thresholds arid 
avatebte resources 

YES 

YES / NO 

8 

Should provide easy management 
through user friendly GUI interface. 

YES 

YES / NO 

9 

Should be compatible and should 
integrate with the backup software 
provisioned. 

YES 

YES/NO 

10 

i 

Support... 



ts the proposed product/solution End- 
oMrfe or wiS reach End-of4ife withm 
24 months from the date of 
submission of bid or 12 months from 
the date of acceptance, whichever is 
later? 

NO 

YES / NO 

' 

Provide new version upgrades. 
updates, patches, etc. for all the 
components / sub-components 
through the period of contract 

YES 

YES/NO 

Will the proposed product/solution 
reach End-of-support during the 
currency of contract? 

NO 

YES/NO 
















D# 
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Technical Specifications for Event Correlation, management and 
monitoring 




SI No 











1 Power Specification 


2 Product Name 


♦ 


•o 




3 Version 

A NetWork Interface 

' ‘ m J ii i M Mi II l i HD 

5 Number of Network Interfaces 

■* * i iiA.it n .i H^iHi.Y rte.An i A ^ *■ . v ■ 

6 number of events 

— * • ■ •** ■■-»'■■-■» *-- - nn ~ « ■ ‘ ■ -- ■- | 

7 number of devices 

_!_* ~ — -» • “ • t ll.tIDI_ 

6 Event/Log ciollectiort storage 


9 Support Log encryption 

10 Support high availability 

— ■■’ ■ ' L *^*—«_/ —j-- . .r .... < . 

11 Log Replication capabilities 

*“*■ " "*—> ■*' H '»*■ » ni it i )»i> <U . ^ U A »a—*—u—— 

12 Data management tools<copy. 
purge and move) 

. ■■ . — ..x«..V uu.«. «*■ ......... 

13 Event/Log collection: 

“■ . . I 1 < I 

Collect events and logs at real 
time to a centralized log and 
Event Management system with 
secure storage 

i 

i- -■ ■* ■ ..*■■ ■ ■» - - , .. , -■ |‘ I _ 

Regular signature and 
vulnerability information 

14 System Device support 
Capabilities 

■-"■‘ | .* ■■■*— .- - ■ ^ 

14 1 Operating system 

■ " .. . ■ hmitJt+mJmiti *- ■ - » - 

support not limiting to MS 
Windows, Linux, Solaris, HP UX, 
AIX 

■■11*111 1 1 -- f -*• —^ A - kl . • | i r \ ■ \ r 1 * i 

14 2 Network Devices 

. m4,i ; I JL*> .. A.* —^ -■ , «-f - -A * ... 

Support device Support not 
limiting to Routers, Switches. 
Wireless Access points 

'"" Hi i ‘ i i;* i* Mh-» •-- ■• - t ... • ■ . 

14 3 Database 

— .. II .f ■■■-’-■> *■fawhll - ■ 

Support not limiting to Oracle, 

MS SQL 

> ' 1 A »■ III I ..»*<■.. I.« ' l..hl.li M 

14 4 Security Device 

.. ■ " ■ " ■ " 11 * .. tu •« -- 

Support not limiting to Firewalls, 
IPS.NIDS. NIPS,HlDS. Antivirus 
(Solutions, IPSec gateways 


Indian power 
specifications in terms of 
Phase, Voltage and 
Frequency 

* •"■•■ ■ > ■ ■* ,j - ■ ~ -- ■■ 

Enterprise event 

correlation, security 
monitoring and 
management 

* *---- - - *>■-> - — I ». 

Latest software with all 
features as required for 
the solution 

* ■ ■ k - - tarn - . - 

1G Ethernet or 10G 
Ethernet 

* -*--■■■*• •- - ■ •_ .. _». 

at least 2 

* . .*** i i ■» ..- - 

minimum 7000 event per 
sec 

miimum 900 devices 

- * . * ■■*■•■ 

at least 1TB storage. 

RAID protected. High 
Performance disks 
yes 

i. ■ tl ■*■-■■ ■, ■—^ - - 1r fr,.' 

yes 

4 —I n I 1 n-s. 

yes 

..-»■*“ ■ -^- i i- - i 

yes i 


0,V.Hz 


unti 


yes 


gbps 


VES/NO 

Al^— WVn t dliHL U 

YES/NO 

yes/nQ 


YES/NO 

AmJ ,« niMili..a«.»<V», 

YES/NO 

YES/NQ 

YES/NO 


YES/NO 


YES/NO 


YES/NO 


YES/NO 


YES/NO 


YES/NO 


14 5 Virtual Environments 

support not limiting to VmwSre, 
V center. Vmware 


YES/NO 
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[ 14 6jC 

1 I s 

ustormzation capabilities to 
upport home grown applications 

es 

'ES/NO 

1 15 I* 

ilert and Correlation 



1 l v 

1 r 

Ip 

Veb based ability to monitor 
nd manage devices which are 
tart of solution 

res 

f'ES/NO 

r 

1 

Correlation support but he* 
united to - Rule Based. 

3ehatfour Based. Vulnerability 
>ased, User defined, Baseline 
>ased 

res 

fES/NO | 


Provide reaMtme dashboard and i 
jtobal view of an data capatured 

/es 



M>Hrty to define the network 
vaseline and alerts 

yes 

YES/NO 


CapabiSty to alert via but not 

Smiting to -email, syslog 
notifications, SNMP traps, 
syslog 

yes 

YES/NO I 

1 16j 

Reports 




Standard reports should be 
available as part of solution and 
made available as and when 
vendor release the upgrade at no 
cost 

yes 

• . 

YES/NO j 

« n 


Ability to schedule standard user 
defined reports 

yes 

YES/NO 


Management 




System should allow multi user 
access 

yes 

YES/NO | 


AAA support for T AC ACS, 
RADIUS. Active Directory 

yes 

YES/NO 1 


Rote Based Access to 
administrator web portal 

yes 

YES/NO 1 

1 18 

Process 


.j 


Support ticketing/workftcw 
management capabilities 

yes 

YES/NO | 


Alow third party ticketing 
systems like but not limited to - 
BMC Remedy. CA Umcenter, 
Service Desk, etc 

yes 

YES/NO 1 


Automatic incident creation 
based on alerts 

yes 

YES/NO | 


Mounting 

Standard 19*in rack with 
required hardware 


X 

Compatability with proposed 
network devices 

Yes 

YES/NO j 

21 

Compatabaity with proposed 

Yes 

YES/NO 1 

22 

l Power Supply 




(N+1) redundant power supply 
proposed 

YES 

YES/NO | 

2 : 

Coding Fans 




(N+1) redundant Cooling Fans 
proposed 

YES 

YES/NO 1 

2* 

Support 




Is the proposed product/solution 
End-of-Hfe or will reach End-of- 
life within 24 months from the 
date of submission Of bid or 12 
months from the date of 
acceptance, whichever is later? 

NO 

YES/NO I 



> 






0 





Unit Price for Enrollment Allotted Transaction forde-duplicatioh services (in INR) 

Item Description 

Base Price 

Total Taxes, Duties 
and Levies 

Total Price 

Price quoted per 
allotted transaction 
for de-duplication 
services 

2.49 

< 

0.26 

2.75 




u 
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Annexure I 



^ Non-Disclosure Agreement as submitted by M/s L-l Identity Solutions 

Operating Company private Limited 
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Technical Bid as submitted by M/s L-l Identity Solutions Operating ci 

Company Private Limited - • 
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Commercial Bid as submitted by M/s L-l Identity Solutions Operating 

Company Private Limited 
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Annexure L 

Acceptance Letter of LI Bidder commercial quote 



iilrl 


• • 


• • 


IDENTITY 

SOLUTIONS 


July J 6,2010 


Shri B. B. Nanawati 
Deputy Director General 

Unique Identification Authority of India (UIDAf) 

Planning Commission, Govt, oflndia (Gol) 

3*° Floor, Tower II, Jecvan Bharati Building 
Connaught Circus 
New Delhi - 110001 

Re: L-l Identity So lotions Operating Company; 

UTDAI -RFP 


Dear Shri.B.B. Nanawati, 


Based on the UIDAJ's request earlier today, the L-l Consortium (“L 
our letter to you dated July 15. 2010 and agrees to match Accenture* 
2.75 Rupees per allotted enrollment transaction. 


-J”)hereby retracts 
lowest bid price of 


We very much look forward to serving the UIDAJ and 
program. 


participating in this important 


Respectfully submitted. 



Machie) van dcr Harst 
Technology Officer, 

L-1 Identity Solutions Operating Company 





/ * 










& 



COO 


I 77 Broad Street. 12th Floor Stamford. CT t)Woi 203o<M-!luo 


o 


- 3^5 


f 

I 








Annexure M 

The Purchaser's order dated 30 th July 2010 
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GOVT OP INDIA 

PLANNING COMMISSION 

UNIQUE IDENTIFICATION AUTHORITY OF INDIA 

3rd Floor, Tower II, Jeevan Bharat! Building, 
Connaught Circus.New Delhi -110001. 

* 

F.No. D-11018/14/Toch/1(MJIDAI - 2 1 S 5 Dated: 30.07.2010 


M/s LI Identity Solution Operating Company, 
2. Frontline Grandeur, 

14 Walton Road, 

Bengaluru - S£0 001 






i 








Sir. 



Sub : Implementation of Biometric Solution for UIDAI - Order 
- Regarding. 


Please refer to the Technical and Commercial Bids submitted by you In response to 
Tender No D-11018/14/Tech/I0*UIDAI on the above mentioned subject and your 
revised financial proposal dated 16 07 2010. 

M/s Accenture Services Pvt Ltd. M/s Satyam Computer Services Ltd (Mahmdra 
Satyam) and M/s LI Identity Solution Operating Company have been selected as the 
three Biometnc Solution Providers for undertaking the scope of work as stated in 
“Section V - Scope of Work" of the Bid Document It may be noted that the 
contract period vyould be 2 (two) years or 20 crores enrolment transactions, 
whichever is earlier 

Accordingly, we are pleased to place an order on M J* LI Identity Solution 
Operating Company, for Implementation of Biometnc Solution for UIOAI, for an 
estimated maximum 10.50 crore enrolment transactions, at a cost of Ra. 2.75 
(Rupees Two and Palse Seventy Five Only) (Including tax®*) per successful 
De-Dupllcatlon 

It should be noted, that subject to “Clause 4 - Non-performance of the Biometric 
Solution and Rules of Allocation'* of Section VIII of the Bid Document, the 
allocation of further enrolment transactions witi be done in accordance with the 
provisions of M C)ause 3 - Rules of Allocation'* of Section VIII of the Bid Document 

Following salient points, inter alia, as stipulated in “Clause 3 - Rules of Allocation** 
of Section VIII of the Bid Document should be noted' 

(i> the enrolment transactions in Cycle 1. i.e, from zero to 1 crore 
transactions shall be assigned to al the above mentioned three 
Biometnc Solution Providers, meaning, each Biometric Solution 
Provider shall perform successful de-dupttcatfon check on the 
same 1 crore subjects, 
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(ii) from Cycle 2 onwards, daily volumes shall be allocated separately to 
Biometric Solution Providers as per “Clause 3 - Rules of Allocation” 
of Section VIII of the Bid Document 

(Hi) for the purpose of allocation of volumes for Cycle 2. performance of 
the Biometric Solution during the last Ten Lakh enrolment transactions 
of Cycle: 

(iv) the performance of the solution of each Biometric Solution Provider 
shall be measured at the end of each Cycle: 

(v) from Cycle 3 onwards (till Cycle 20), the allocation of volumes to 
Biometric Solution Provider shall be based oh performance 
measurement made on their respective solution for at) transactions 
undertaken in the previous Cycle. 

(vi> The Biometric Solution of each Biometric Solution Provider shall 
adhere to performance levels as stated in Clause 7.2 of Section HI 
Attachment 1 — Draft Service Level Agreement of the Bid 

Document. 

6. Stipulated Time Schedule 

The Project Timelines for Implementation of Biometric Solution shall be as stipulated 
in ‘’Clause 21 of Section III - General Terms and Conditions of the Contract” of 
the Bid Document and should be strictly adhered to. 

7 Server, Storage and Other Infrastructure 

In accordance with 'Clause 8 of Section V - Scope of Work” of the Bid Document 
you shall provide hardware for both primary and business continuity sites of UIDAI for 
de-duplications of an estimated capacity of 1 (one) Crore enrolments. The payment 
of Rs. 5,00,00,000/- (Rupees Five Crones only) towards delivery, installation, 
acceptance etc. will be made to you in accordance with “Clause 46 - Payment 
Schedule” of “Section III - General Terms and Conditions of the Contract” of the 
Bid Document. 

8. Acceptance of Solution 

It shall be your responsibility to draw the acceptance schedules, detailed acceptance 
tests, formats for acceptance reports and dissemination mechanism for the 
acceptance reports in consultation with the UIDAI and as specified in Clause 10 of 
'Section V - Scope of Work” of the Bid DocumeriL 

9. Training 

As part of system implementation, you shall impart training, to staff of UIDAI and of 
service providers as nominated by UIDAI, on the Biometric solution related to 
configuration, usage. API. performance tuning and measurement and Technical 
reports as indicated in 'Section V - Scope of Work” of the Bid Document. 

10. Payment Terms 



Payments will be made to you in accordance with “Clause 46 - Payment Schedule” 
of 'Section III - General Terms and Conditions of the Contract” of the Bid 
Document. 

11. Scope of Work and Deliverables 

The Scope of work. Deliverables etc. shall be as per "Section V - Scope of Work” 
of the Bid Document and the Technical Bid submitted by you. 


© ♦ 
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12. Warranty 

The Warranty shaH be as per the agreement to be signed m this regard, and will be 
as described in the General Conditions of Contract attached thereto. 

13. Signing of Contract 

Based on your technical and financial bids, and the subsequent discussions held 
from time to time in this regard, a formal contract would be signed with you. 
Accordingly, you are requested to come for signing of the formal contract on receipt 
of this order. Pending signing of the formal Contract, this order shall be governed by 
the General Terms and Conditions of the Contract, Service Level Agreement and 
Work Allocation & Service Levels as stipulated in Section II. Section III (Attachment 
1) and Section VIII respectively of the Bid Document 

14. Performance Security 

Within 15 days after receipt of this order. M/s LI Identity Solution Operating 
Company shall have to furnish the performance security to the UIDAI, in the form of 
a bank guarantee bond from a Nationalised Bank / Scheduled Bank, for an amount of 
Rs. 3,38,75,000/- (Rupees Three Crores Thirty Eight Lakhs Seventy Five 
Thousand only), which shall be equal to 10 percent of the estimated value of the 
order (comprising of Rs. 5 crores of hardware costs and Rs. 28.875 Crores for 
estimated maximum 10.50 crore enrolment transactions). 

15 This issues with the approval of the Competent Authority. 


Yours faithfully. 


(A™ 



(Ajay Nandan) 
Assistant Director General 
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transactions for a Biometric Solution Provider, during normal Operations shall not go 

beyond fifty percent (50%) of total daily enrolment transactions irrespective of the 
performance in the previous cycle. 

v. For the purpose of allocation of volumes for Cycle 2, performance Of the Biometric 
Solution during the last Ten Lakh enrolment transactions of Cycle 1 (only the first one 
crore enrolment transactions) shall be considered. 

vi. The performance of the solution of each Biometric Solution Provider shall be measured 
at the end of each cycle based on computation of Accuracy, Speed of the solution and 
Hardware Resources used using test cases provided by UIDAI. 

vii. From Cycle 3 onwards (till Cycle 20), the allocation of volumes to Biometric Solution 
Provider shall be based on performance measurement made on their respective 
solution for all transactions undertaken in the previous cycle. Hence, the relative 
performance of a Biometric Solution in the previous cycle shall determine the allocation 
of the enrolment transactions for the next cycle. 

viiL The Biometric Solution of each Biometric Solution Provider shall adhere to performance 
levels as stated in Clause 7.2 of Annexure C - Service Level Agreement. 
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4. Non Performance of a Biometric Solution and Rules of Allocation 

i. Any drop in accuracy of the de-duplication checks by the Biometric Solution Provider 
below certain limits as specified by UIDAI shall be treated as non performance of the 
Biometric Solution Provider. The accuracy shall be measured in form of service levels 
under category 'Accuracy' in Clause 7.2.1 of Annexure C - Service Level Agreement. A 
measurement of service level below the stated limits shall be treated as non 
performance of the Biometric Solution. 

ii. In the event of non performance by a Biometric Solution due to poor accuracy, as 
measured using the Service Levels at the end of each cycle, the Biometric Solution 
Provider shall only receive fifty percent (50%) of volumes it is entitled to in the next 
cycle, i.e., based on regular computation of allocations across the Biometric Solution 
Providers in normal operations. 
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a. In such a case, the remaining fifty percent (50%) of volumes that would have 
otherwise been allotted to the non performing Biometric Solution Provider during 
normal operations shall be distributed equally to other Biometric Solution Providers 

b. The transfer of enrolment transaction volumes to other Biometric Solution Provider 
shall add to the volumes allotted to them as per the regular computation during 

nqrmal operations. 

c. The limit of maximum allocation to a Biometric Solution Provider as stated in Rule 4 
in Clause 4 - Rules of Allocation above (maximum of 50%) shall not be applicable in 
such cases, meaning, a Biometric Solution Provider may receive more than fifty 
percent of total enrolment volumes in a cycle on account of non performance of one 
or more of other Biometric Solutions. 

In the event of non performance by a Biometric Solution due to poor accuracy, as 
measured at the end of each cycle, the Biometric Solution shall be kept under Probation 
and its performance shall be reviewed at the end of the Allocation Cycle 


a. If the performance, in terms of accuracy, of the solution in the next Cycle 
meets the acceptable service level targets under category 'Accuracy' in 
Clause 7.2.1 of Annexure C - Service Level Agreement., then the Biometric 
Solution Provider shall be relieved of Probation and shall be allowed to 
resume normal operations. 

1. On resuming normal operations, the Biometric Solution Provider shall be 
allotted its full share of the allocations for the next cycle as computed 
across all Biometric Solution Providers. 

2. All service levels would be measured as per the criteria to be defined by 
UIDAI. 

b. If the performance, in terms of accuracy, of the solution in the next cycle, 
continues to remain below the minimum acceptable level, then the non 
performing Biometric Solution shall be moved out Of production and kept 
under Rehabilitation. 

1. Under Rehabilitation, the non performing Biometric Solution shall not 
receive any allocation of enrolment transaction volumes from the next 
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cycle onward unless it successfully meets the acceptance criteria of the 
testing conducted by UIDAI every quarter. 

2. In such a case, all the volumes that it was entitle to allotted during 

normal operations shall be distributed equally to other Biometric 
Solution Providers. 

3. The transfer of enrolment transaction volumes to other Biometric 
Solution Provider shall add to the volumes already allotted to them. 

4. The limit of maximum allocation to a Biometric .Solution Provider as - 
stated in Rule 4 in Clause 4 - Rules of Allocation above shall not be 
applicable in such cases, meaning, a Biometric Solution Provider may 
receive more than fifty percent of total enrolment volumes in a cycle on 
account of non performance of one or more of other Biometric Solutions. 

5. The performance of the Biometric Solution under rehabilitation shall be 
reviewed at the end of the quarter by UIDAI by conducting a test using a 
separate test bed of enrolment volumes. Please refer to the Clause 4.1 - 
Performance Testing of Biometric Solution for more details 

• The Biometric Solution Provider may choose to undertake the test 
before the end of the quarter. However, the cost of such early 
testing shall be fully borne by the Biometric Solution Provider 

6. If the nOn performing Biometric Solution Provider successfully meets the 
acceptance criteria of the testing conducted by UIDAI, it shall be shall be 
relieved of Rehabilitation and shall be allowed to resume normal 
operations by moving into Production. 


• On resuming normal operations, the Biometric Solution Provider 
shall be allotted 10 Lakhs transaction for the next cycle Biometric 
Solution Provider 

a. On meeting the service levels successfully as measured at 
the end of the cycle, the Biometric Solution Provider shall 
be given its full share of allocations for the next cycle 


b. If the Biometric Solution fails to meet the minimum service 
levels for the allotted 10 Lakh transactions, the contract of 
the Biometric Solution Provider shall be terminated 
immediately 
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7. If the non performing Biometric Solution does not meet the acceptance 
criteria of the testing conducted by UIDAI, the contract of the Biometric 
Solution Provider shall be terminated immediately. In such a case, UIDAI 
reserves the right to appoint another Biometric Solution Provider in 
addition to the existing Biometric Solution Providers 



4.1 Performance Testing of Biometric Solution 

ABIS will be tested on performance using continuous and period testing. 



r h 



Continuous Testing: Continuous testing shall cover measurements for the following 
parameters: 



1. Speed: throughput rate per day 

2. Hardware utilization: utilization of hardware for quality check, template generation, 
insertion and de-duplication (IDENTIFY method) each 

3. FMR and FPIR 

Periodic Testing 



t 

The periodic testing will involve use of probes with known duplicates and non-duplicates to 
measure FMR, FNMR, FPIR and FNIR. Prior to probes, the vendor will be provided sufficient 
training data to tune ABIS. It is the intention of UIDAI to generate near continuous "probe" data 
to generate continuous FNMR and FNIR. 

Each ABIS will be expected to perform with an accepted band of performance in each Of three 
dimension — Speed, accuracy and resources (H/W, power, DC space etc.). If any ABIS crosses 
acceptable band, reallocation of the workload will be triggered. 



The reallocation of workload, subject to conditions listed above for the SLA, will be based on 
accuracy, speed and resource optimization. The basic principle governing relocation is to 
optimize accuracy while maintaining requisite speed for a given configuration. The precise 
formula will be provided at the time of the reallocation event. UIDAI reserves the right to 
change the governing principle if Operating constraints are changed 

5. Service Level 

For details of Solution related performance levels, please refer to Clause 7.2 of Annexure C - 
Service Level Agreement. 
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Scope of Work 


1 Introduction 

1.1 Objective 

The aim of this Request for Proposal is to select three Biometric Solution Providers to 
design, supply, install, configure, commission, maintain and support (a) multi-modal 
Automatic Biometric Identification Subsystem (ABIS) and (b) multi-modal Software 

Development Kit (SDK) for client enrollment station, verification server, manual adjudication 
and monitoring function of the UID application. 

1.2 Background 

The UIDAI has been setup by the Government of India with a mandate to issue Unique 
Identification numbers (UID Numbers) to all the residents in the country. UIDAI proposes to 
create a platform to enroll the residents of the country, issue UID Numbers. These numbers 

may then be used for authentication. This can be used by several Government and private 
organizations for better delivery of services to residents. 

/ 1.3 Intent of UIDAI 



The purpose of the UIDAI is to issue UID Numbers that are (a) robust enough to minimise / 
eliminate duplicate and fake identities, and (b) can be verified and authenticated in an easy, 
cost effective way. UIDAI will use common demographic and biometric data for establishing 
and verifying identity, therefore, it becomes essential to standardize these data fields and 
verification procedures across its registering partners (Registrars). This will aid 
interoperability across many systems that capture information and work with the residents 


UIDAI has selected biometrics as the primary method to check for duplicate identity 

records. In order to ensure that an individual can establish their identity uniquely in an easy 

and cost-effective manner, it is essential that the captured biometric information is of a 

quality and standard that is capable of being de-duplicated. Further, for authentication of 

identity at the time of service delivery by Government and private organisations it is 

essential that the biometric information capture and transmission are standardized across 
all users of the UID Application. 


In order to set these standards two committees were set up by the UIDAI. The Demographi 
Data Standards and Verification procedure Committee constituted underby UIDAI and th 

u! 0 nT. etn< K S COr T itt / e , e ^ SUbmftted th6ir fina ' rep0rts - These "*** ^e available on th, 
UIDAI website http://uidai.gnv in 
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1.4 Understanding UID System 

India will be the first country to implement a biometric-based unique ID system on such a 
large scale. The UID will serve as a universal proof of identity, allowing residents to 
establish their credentials anywhere in the country. It will give the Government a clear view 
of India's population and enable it to track and deliver services and resource flows 
effectively, thereby achieving greater returns on social investments. Confirming 'you are 
who you say you are' remains the primary, often elusive goal Of all identity systems. 

The UlDAJ approach - which will be online authentication, with biometric check - creates a 
very strong authentication system, and gives the UlDAI significant ability to confirm an 
individual's identity. The UlDAI will support the Registrars in building the infrastructure and 
systems necessary to authenticate residents in different parts of the country. This will be 
especially critical for Registrars working in rural areas and among the poor. 
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1.5 Goals of UID System 

For details on the goal of UID system, refer to the document on UlDAI's website titled 
Creating a unique identity for every resident in India - ‘Draft approach" 

iltHc//yjdajgoy.in/docu ments/Creating%20a%20uniQue%20identitv%20for%20eveiV%20re 

sident%20in%20lndia.pdf 

1.6 Key Features of UID System 

1. Identity — every resident can have a lifelong ID number that will be commonly 
accepted across multiple systems within India. That number will be linked to limited 
demographic information, such as name, residence, date of birth and gender, 
establishing an official "identity" for each resident. 

2. Authentication - Is the process of ascertaining a person's identity, supports 
answering the basic question "is a resident the person he/she claims to be". 

3. Standardization - Standardization of Know Your Resident (KYR) Data and Processes, 
and Biometric Standards in order to achieve interoperability across organizational 
users of the system. 
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1.7 Glossary 


Table 1 - Glossary 


Term 

Definition or Meaning 

UIDAI 

*-- ■■ ■ _... . 

The regulatory body that will design, develop, and deploy the UID I 
Application with the help of service providers 

Registrar 

Any Government, private or non-Governmental agency that can 
enroll and authenticate residents using the UID Application. 1 

• 

Enrolment Agency 

T"*— > » — f . .. ■ ,..ym ■ ~T h*..-...-- _ ... 

me agency that will actually enroll residents by capturing their 1 
demographic and biometric information in the field. They will be 
setup or employed on behalf of the Registrar 

UlO Server 

The central server that responds to enrolment and authentication 
requests. 

Registrar System 

The registrars IT systems and processes I 

Enrolment Client 

Software provided by the UIDAI to Registrar/Enrolling Agencies in 
Order to enrol residents into the UID system. 1 

Biometric Solution 

Consists Of two biometric components: ABIS and multi-modal SDK. 1 

ABIS API 

API to communicate between UID Application & ABIS. 1 

BSP 

--■*■*>— .... 

Biometric Solution Provider supplying biometric solutions (ABIS and 1 
multi-modal SDK). 

MSP 

----——- 

Managed Service Provider ] 

CIDR 

Central Identity Repository, which is the database and de-1 
duplication/verification application 

BCP 

--———*- 

Business Continuity Planning 

Verification 

1 ne process of comparing a query biometric sample to a stored j 

biometric reference to determine if they came from the same 
person 

Authentication 

The process of validating a claim that a UID number belongs to a 
particular resident using biometric Or non-biometric means 

UID Application 

UlD Software for enrolment and authentication, in the current 
context, it is used to indicate non-biometric portion of UID software. 
Occasionally, it is a synonym for UID server. 

Scaled fusion 

Score of similarity returned by ABIS. Also called normalized fusion 

. . * 1 1 » . 
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Term 

Definition or Meaning 

score 

score. It ranges between (0 and 100) where 100 is most similar and 0 
is least similar. 

SDK 

Software Development Kit comprises of computational algorithm for 
quality analysis, segmentation, feature extraction, comparison score 
generation for fingerprint, iris and face modalities. 


2 Stakeholders 

2.1 Unique Identification Authority of India (UIDAI) 

♦ 

UIDAI has been setup by the Government of India with a mandate to issue Unique 
Identification numbers (UID Numbers) to all the residents in the country. It is regulatory 
body responsible for the success of the entire project. 


2.2 UIDAI Technology Team at Bengaluru: 

The technology team works under the direction of UIDAI to design, develop and advise on 
the technology solution. 



2.3 Biometric Solution Provider (BSP) 

A BSP shall work under the direction of the technology team to design, supply, integrate, 
install, commission and maintain the biometric solution. 



© 



2.4 Project Management Consultant (PMC): 

PMC shall assist UIDAI in defining the scope Of services and selecting BSP and Managed 
service Provider, in selecting data center and providing Overall project management of the 
r/ CIDR project. M/s Ernst & Young Pvt Ltd has been selected as the PMC. 


© 2.5 Application Software Development, Maintenance and Support Agency (ASDMSA): 

© ASDMSA provides application software development and maintenance services for the UID 

application. ASDMSA will develop biometric based enrollment software. ASDMSA will 

• develop and assist in testing biometric solution interface. M/s Mind Tree Ltd. has been 

A selected as ASDMSA. 


© 







2.6 Project Management Unit (PMU): 


UlDAI has set-up a Project Monitoring Unit (PMU) at its headquarters, to monitor the timely 
and effective implementation of the project. The PMU will be responsible for the overall 
planning and execution of the UID project, under the guidance of UlDAI. 


2.7 Managed Service Provider (MSP) 

* •• 

MSP operates data center, manages UID application, is responsible for overall operation 
and logistics and supports registrar on-boarding. MSP is expected to be selected in October 
2010. 

2.8 4 Data Center (DC) 

The entire UID application, with the exception of the enrollment centers and authentication 
request stations, will be housed at the Data Center (DC), initially a single physical center, but 
potentially dividing into multiple centers during the course of the project. The DC will 
provide infrastructure facility, off-site backup storage and support movement of physical 
material between DC and Disaster Recovery Center. 

3 UID System Overview 

3.1 High Level System Overview 

The UID Server System consists of the UID application existing within a cloud computing 
environment. UID Server System is deployed centrally on one or distributed over many data 
centers and provides various services over a secure network. Main application modules are 
"Enrolment Module" and "Authentication Module". In addition, various other modules for 
administration, analytics, reporting, fraud detection, portal user interface, etc. are also part 
of the UID Server System. 
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Figure 2 - UID Enrolment Client System 
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On the other hand, UID Enrolment Client is a rich client application that can be deployed on 

# a large number of computers in the field and works in offline disconnected mode. 

Enrolment agencies will use the client software within their systems to enrol residents in 
the field and upload data onto the server in a batch mode. The BSP will supply only an SDK 

• (described later in this document) that is will be embedded in the Enrolment Client 
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3.2 Biometric Solution Design Principles 

1. Modularity: The design- must allow for replacement and updating of components, 

perhaps from various vendors, without any impact on the remaining components The 

components in this context should be as fine grained as possible. For example, the 

enrolment server and authentication server are fully decoupled and will use separate 
database and could use different matcher. 


2 . 


3. 


4. 


5. 


Standards: Use of the standards prescribed by UlDAI is mandatory. All interfaces to the 

outside systems must be based on current industry standards adopted by UlDAI for 

maximum interoperability. Use of open source also aids in standardization. 

Avoidance of vendor lock-in: In the area of biometrics, proprietary algorithms and data 

representation are perhaps required to achieve performance and accuracy 

requirements of the UlDAI. The system is designed such that these algorithms and date 

representation form a part of the black box, and the entire box or a sub-system can be 

rep aced without any impact on the other biometrics black boxes. For example, one can 

replace biometric de-dupl,cation module without any impact on the biometric 

verification module. All proprietary data formats needed within each solution are not 
exposed outside of the black box. 1 

Resident Convenience: The entire process of enrolment and authentication must be 

conducted with strict conformance to quality and precision. At the same time the 

process wm provide transparency, flexibility and convenience to the residents' For 

example, the collection of biometric features wil, have user interface that is consistent 
with these requirements. 

Risk Mitigation: India is the largest country to undertake biometric collection of the 
entire population and biometric authentication for service delivery. BSPs are yet to build 
systems or, such a scale. Consequently it is not possible to predict scalability of the 
present offerings against the demographics of India. As the quality and availability of 
biometric measures across the population is currently not known, alternate methods for 

de-duplication and fall-back strategy must be incorporated in the design should the 
primary strategy fall short of the UlDAI goals. 
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6. Universality: To support scalability and inclusiveness of the solution, three biometric 
modes will be collected fingerprint, face and iris. Ten fingerprints will be collected as 

slaps ("4-4-2"). Iris images will be collected in pairs and facial image will be full 
frontal. The deduplication should utilize fingerprint and iris images. 

7. Security: Biometric Solution must be secure and conform to Government of India's data 
security and UID's security guidelines, including encryption and decryption. For example, 
all personal information stored on a permanent storage media must be encrypted. 

8. Enrolment data quality: The quality of data depends on enrolment process and 
technology. UlDAI will use best practices for enrolment process and utilize optimum 
technology to capture best quality of data while ensuring that no one is denied 
enrolment due to poor biometric data. A number of techniques such as operator 
enrolment and verification of enrollee's biometric against all registered operators and 
supervisors will be performed at the enrolment station. 

9. Service Oriented Architecture: The biometric components follow SOA principles. They 
provide specific services using well defined interfaces. 

10. Isolation. ABIS will not have access and should not try to access any network resources 
except the resources referenced by the URLs provided through the API. 

11. DBMS - The DBMS should be compatible with RDBMS of UlD application and should be 
able to import/export data with ease 

12. Distributed Database - Solution should provide distributed database for the purpose of 
authentication 
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3.3 System level Information flow 
3.3.1 Enrolment Process Information Flow 



Figure 3 - UID Enrolment Process Information Flow (Orange indicates components to be provided by the BSP) 

The UIO enrolment client is a rich client application being developed by the UIDAI. Further details of the information flow can be 

found in ASDMSA Volume II. The BSP will provide SDKs to support the collection, pre-processing and matching of face, iris and 
fingerprint dat 
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3.3.2 Enrolment Server 
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Figure 4 - Enrolment Server Information Flow 
(Orange indicates components to be provided by the BSP) 

The enrolment server is a logically centralized system running on the e-governance cloud. Further details of the information flow 

can be found in ASDMSA Volume II. The BSP will be fuHy responsible for the biometric de-duplication module within the Biometric 

De-Duplication Layer (Layer 2 in Figure 4h including maintenance of a de-duplication database and a physically separated and 
synchronized disaster recovery database. 
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3.4 Authentication Server ' 



Figure 5 Authentication Server Information Flow 
(Orange and yellow indicate components to be provided by the BSP) 
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Online authentication, to validate the residents' claim to UID numbers at points of service, 

is supported by the UID system. Approaches to verification can be flexible to accommodate 
different levels of assurance: 

• Online demographic authentication, where the authenticating agency compares the UID 
number and demographic information of the UID holder to the information stored in 
the UID database. The assurance level here is medium and does not involve the BSP. 

• Online biometric verification where the biometrics of the UID holder, his/her UID and 
key demographic details are compared to the details in the CIDR. The comparison of 
submitted biometric samples to stored biometric references to support this process will 
be the responsibility of the BSP. The assurance level in this case is high. 

UIDAI expects an extremely large volume of verification requests each day once the UID 
number is widely adopted within various systems across the country. To cater to such large 
volumes, all verification requests are "stateless", containing all information required for the 
verification transaction within each request message. This means that no "state" should 
ever be maintained on the server and every request should be serviced as if it is a new 
request. Authentication clients should maintain necessary state during interaction with the 

resident to allow error handling, retries, and overall provide a friendly experience to 
residents. 







4 Biometric solution Components 

*s * * 

Two biometric components are utilized in five modules of the UID System. The biometric 
components are: 

1. Automated Biometric Identification Subsystem (ABIS): ABIS will be used in the 
Enrolment Server as a part of the multi-modal biometric de-duplication solution. In the 

i 

early release, ABIS will also be used in the Authentication Server for verification. The 
ABIS will maintain its own database of proprietary fingerprint and iris templates for de- 
duplication (and face templates at the discretion of the vendor), and must be able to 
respond to verification requests accompanied by fingerprint and/or iris images, as well 
as ISO/IEC 19794-2:2005 format fingerprint minutiae files. Vendors will work with the 

UIDAI to provide further specification within 19794-2 to promote interoperability with 
future verification clients. 


2. Multimodal SDKs: SDKs will be used in the enrolment client, manual check (for 
duplicates), authentication server (for later releases) and the analytics module. The SDK 
may contain signal detection, quality analysis, image selection, image fusion. 
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segmentation, image pre-processing, feature extraction and comparison score 
generation for fingerprint, iris and face modalities. 

In summary, the following UID System modules utilize biometric components: 

1. Multi-modal de-duplication in the enrollment server 

2. Verification subsystem within the authentication server 

3. Enrolment client 

, 4. Manual checks and exception handling 
S. Biometric sub-system monitoring and analysis 

The functional requirements of the five areas are described; followed by the overall 
functions of the two biometric components. 
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4.1 UID System Requirements of the biometric components 

4.1.1 Multi-modal Biometric de-duplication in the Enrolment Server 

Considering the expected size of the de-duplication task, the UID enrolment server will 
utilize: 

1. Multi-modal de-duplication. Multiple modalities - fingerprint and iris will be used for 
de.-duplicatiori. Face photograph is provided if the vendor desires to use it for de- 
duplication. While certain demographicol information is also provided, UIDAI 
provides no assurance of its accuracy. Demographic information shall not be used 
for filtering during the de-duplication process, but this capability shall be preserved 
for potential implementation in later phases of the UID program. Each multi-modal 
de-duplication request will contain an indexing number (Referenced) 1 in addition to 
the multi-modal biometric and demographic data.. In the event one or more 
duplicate enrolments is found, the ABIS will pass back the Referenced Of the 
duplicates and the scaled comparison scores upon which the duplicate finding was 
based. The scaled fusion score returned with each duplicate found will have a range 
of [0,10D), with 0 indicating the least level of similarity and 100 as the highest level 
of similarity. 


' ABIS will not be aware of the UID it, nor will it be aware of how UID #maps to reference ID or 
records in the reference DB. 
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2. Multi-vendor. Multiple complete multi-modal solutions from more than one vendor 
will be used as shown in 


UID Application: 
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Figure 6. The UID Application will determine routing of a particular de-duplication 

request. It may determine to route a particular de-duplication request to more than 

one biometric solution, if it routes a de-duplication request to more than one 

solution, it is responsible for determining the final outcome of the de-duplication 

request. In other words, fusion of the scores across the multiple ABIS is not within 

the scope of this RFP. The UID ABIS API specifies the interaction between UID 
Application and ABIS. 

The middleware-included in the UID application (being developed by ASDMSA) is 

meant to provide vendor independence and standardization. The key features of the 
middleware is 

a. Routing and mediation. 

b. Guaranteed delivery 

c. Fault tolerance and load balancing 

d. Open standard based messaging (AMQP) using open source RabbitMQ 
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e. 


Transparent connectivity to analysis and system monitoring modules of UID 
applications 


f. 


Support of web 2.0 based UID ABIS API and CBEFF data format standard 


g- 


Encapsulation and isolation of ABIS components 
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UID Application: 

Enrolment & Authentication Server 


® sourcG^: 5 ’"" ;-N 

,C T - '- 1 « 1 .•*'<> ' 4 V- ■ > ■ v ' ’ * ' - *» • ■ . : *’ -1 1 , . i fc * 

\1: ■' . *.- * - , -.* • -— \ . „ 4 y ' >. A ' _V':.^ ■.* *' v: ,,1!l " v / • . : " v , t '■ > * "* < T': y ;'/ v * 



UID ABIS API 


* \ vm • .-a*;-ifV*. P '•{ >, 



ABIS Solution 1 



r VssVUit* 


ABIS Solution 2 



Figure 6 Authentication Server De-duplication 
(Orange indicates components to be provided by the BSP) 




4.1.2 Verification Subsystem of Authentication Server 

In the first release of the UID server, the biometric verification module, as shown in Figure 
7, provides verification within the authentication server. The solution should be capable of 
1:1 verification comparisons of enrolled references with incoming ISO/IEC 19794-compliant 

9 

fingerprint, iris or face images or 19794-2 compliant fingerprint minutiae sets without 
proprietary extended data. Figure 7 illustrates both the verification and de-duplication 
subsystems to be supplied by the BSP. 
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For the purpose of distributed authentication by UIDAI at a later stage, the biometric 
verification module may be constructed using SDK. While the functionality of the 
verification subsystem will not change, the internal architecture may change. The templates 
will be maintained in memory resident database by the UID authentication server 
application (not in scope of BSP). If the incoming requests contain a biometric image, the 
Authentication server will use SDK to extract the feature. SDK will also be used to generate 

comparison score of the sample. The decision for distributed authentication will rest with 
UIDAI and will be binding on the BSP 
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Figure 7 Verification and De-duplication Server 
(Orange indicates components to be provided by the BSP) 
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4.1.3 Enrolment Client 


The multimodal SDK to be supplied by the BSP should include the following functions 
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1. Fingerprint Slap Segmentation / Sequence Check. Upon fingerprint image capture, it 
may be required to check if the correct slap was captured, and also segment it into each 
digit. 

2 . Quality check. Each modality image requires checking for capture quality to initiate re¬ 
capture if needed and provide actionable feedback (such as guidance on finger 
repositioning) to the operator. 

3. Image enhancement. Face photos may require image enhancement such as auto 
cropping and auto rotation to meet industry standard. Iris images may require cropping 
to K1NDCR0PPED (formerly called Kind 3) or KIND_CROPPED_AND_MASKED (formerly 
Kind 7) format. No gray-level image alteration will be allowed. 

4 . Feature extraction. In a number of cases, fingerprints, faces and/or irises will be 
matched locally. Such cases include verification of operator or supervisor authorizing 
override requests and local de-duplication of enrolled images. The client software will 
need to extract features locally. If sufficient features cannot be extracted, the client 
software may require re-capture. 

5. Template generation. In a number of cases, fingerprints, faces and/or irises will be 
matched locally. Such cases include operator and supervisory override and local de- 
duplication. The client software will need to generate template locally. 

Compression and format conversion. The image may have to be converted from one 
format to another (example, BMP to .PNG) or may have to be 
cornpressed/decompressed (WSQ or JPEG 2000) prior to storage. 

7 . Identification (l:Nf ew ). To reduce fraud and prevent unintentional errors, the client 
software will perform l:N few identification. A typical case of such identification is to 
ensure that the same person does not return to the same enrolment station within a 
short period of time. This includes fingerprint, face and iris. Another scenario pertains to 
supervisor override during which the supervisor's fingerprint will be captured and 
verified. In such cases N is expected to be of the order of a few thousands. 

One or more SDK libraries will be used to support enrolment client requirements. 

4.1.4 Adjudication and exception handling 

In the event of a duplicate determination during enrolment, or in small number of cases 

when the biometric solution is not able to make a clear "duplicate/no duplicate" decision, 

images and enrollment data will be sent for manual check. The Adjudication workstation is 

part of the UID application and is outside the scope of current RFP. However, the 
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workstation needs certain biometric functions that are provided by the SDK. The 
workstation will need access to the functions described in Clause 4.1.3. 
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4.1.5 System Monitoring & Analysis 

The system monitoring and analysis modules of UID application require information from 
the enrolment and authentication systemto perform the following: 

1. Monitor comparison score distributions 

2. Monitor quality of the input data 

3. Compare performance and analyze de-duplication rislcacross_parallel ABIS systems. 

4. Metrics helpful in analysis of possible enrolment/verification fraud and system 
intrusion 

BSP is expected to assist ASDMSA and MSP to design and implement above functionality 
and do troubleshooting and resolution of issues. 

4.2 Biometric Components 

BSP is required to provide ABIS including but not limited to middleware, reference database 
and fusion algorithms as per requirements indicated in clause 6.2. 

BSP shall also provide a separate multi-modal SDK for: 

1. Authentication 

2. Enrolment client 

3. Adjudication and 

4. System Monitoring and Analysis 
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Please refer to clauses 6.2 and 6.3 for more details on ABIS and Multimodal SDK 
respectively 


4.2.1 Automated Biometric Identification System (ABIS) 


ABIS used in the Enrolment Server and Authentication Server should provide de-duplication 
and verification functions. It should communicate with the UlD System through the UID 
Biometric API. As per API specifications, ABIS provides the following functions 
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Shutdown 

Insert 

Verify 

Clear 

Identify 

Ping 

Ping 

Delete 


GetPendingRequests 

Ping 


GetReferenceCount 




Each ABIS shall maintain its own database of indexed biometric references (called the 
reference database) as well as a synchronized disaster recovery database at a separate 
physical location. This reference database is separate from UID database that is outside of 
ABIS and not accessible to ABIS. All information necessary for ABIS to perform its functions 
is maintained by ABIS in the reference database. 

ABIS is expected to use both fingerprint and iris for de-duplication. The BSP may choose to 
use face photo 1 for de-duplication within the ABIS as well. 

CLEAR and SHUTDOWN methods have additional level security and can be sent to the ABIS 

0 / the UID application only after careful validation of the authorizations of the requesting 

party. 

♦ 

4.2.2 Multimodal SDK: 

The SDK is a set of libraries that provide following functions and should be provided and 
kept updated with patches and upgrades. 

4.2.2.1 Fingerprint 

1. Slap Segmentation / Sequence Check 

2. Quality check with actionable feedback 

3. Image compression/de-compression 

4. Feature extraction & Template Generation 

5. Identification (l:Nf ew ) 

6. Verification (1:1) 


1 While the objective is to capture face photo per ICAO standard, there is no assurance that 
consistency could be maintained due to diverse capture conditions. 
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4.2.2.2 Iris 

1. Quality check with actionable feedback 

2. Segmentation/cropping 

3. image compression/de-compression 

4. Feature extraction & template generation 

5. Identification (l:Nf ew ) 

6. Verification (1:1) 

4.2.2.3 ' Face Photo 



1. Automatic capture 

2. Quality check with actionable feedback 

3. Image enhancement (cropping and rotation) 

• . 

4. Image compression/de-compression 

5. Feature extraction & template generation 

6. Identification (l:Nf e w) 



7. Verification (1:1) 

Although automated face recognition is optional within the ABIS, this capability will be 
required of SDKs for various applications, such as Adjudication and exception handling. 

BSP shall supply the UlDAl with a perpetual, fully paid-up, enterprise/world Server and 
Desktop license to use the BSP's proprietary Multimodal SDK for use within the applications 
developed by UlDAl or by its authorized contractors/subcontractors for the purpose Of the 
UlD Program. As provided in L-l Identity Solutions Operating Company's licensing policy in 
its Technical Bid, the Purchaser (including its authorized contractors/subcontractors) are 
oermitted to: (a) make and install copies of the Multimodal SDK software On Purchaser 
owned or controlled server and desktop computer system hardware (the "System" Or 
'Systems") located at UlDAl owned or controlled facilities; (b) use the Multimodal SDK 
software and related documentation for the Purchaser's own internal use in developing 1:1 
and l:few custom solution applications (the "UlDAl Custom Applications") containing 
Multimodal SDK software components in furtherance of the UlD Program; (c) use the UlDAl 
Custom Applications solely in furtherance of the UlD Program; (d) publicly demonstrate the 
UlDAl Custom Applications on Systems; and (e) make and deploy copies of the UlDAl 
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Custom Applications to government and non-government entities and grant such parties a 
limited sublicense to use the UIDAI Custom Applications solely in furtherance Of the UlD 
Program. The Purchaser will require its authorized contractors/subcontracts that support 
the Purchaser with developing applications from the Multimodal SDK to execute 
confidentiality agreements that protect the confidential nature of L-l Identity Solutions 
Operating Company's proprietary Multimodal SDK. 

4.2.2.4 SDK API (planned) 

In the first release of UlD Application, SDK will be invoked using its native API. A service 
oriented vendor independent API for SDK is planned to be released in July 2010. The vendor 
wiii be required to provide update to the SDK compliant with the SDK API after the release 
of the API. 

5 Guiding factors for The Biometric Solution 

Various UIDAI administrative policies will impact the design and operation of both the ABIS 
and the enrolment stations. In this section we enumerate the current policies. 

1. Generally identification function can rely on the sequence of the fingerprint and eyes. 
However in the case that there are missing fingers, extra fingers, hand abnormalities or 
when the confidence of the segmentation is low, the identification should not rely on 
the sequence of the fingers. 

2. Iris images will be automatically labeled by the capture device as left or right and 
therefore this label may be used to restrict iris searches for de-duplication. 

3. The ABIS system should not restrict the search on the basis of demographics (gender, 
age, location) initially, but this capability should be preserved for potential insertion at a 
later stage in the program. 

4 . With regard to slap fingerprints, search outcome should not be impacted by inversion of 
thumb placement. 

5. Face photo image enhancement at the enrolment stations may include cropping and 
• rotation, but must not include non-reversible gray-level alterations (i.e., pose and 

illumination normalization). 

6. The ABIS system must create a record in the reference database whenever UlD 
Application invokes INSEPT method regardless of biometric image quality. 
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7. With the growth of the database, UIDAI may require the vendor to enhance or replace 
algorithm. The ABIS should be structured to allow for replacement, enhancement or 
insertion of new algorithm. 

8. De-duplication flow over multiple modality can be chosen by the vendor. However, 
.UIDAI may upon review of results, may require that vendor must perform de-duplication 
on both modalities fully. 

9. Authorizations for all requests will be verified at the UID application level. Therefore, all 
requests sent by the UID application to the ABIS can be assumed to be from an 
authorized source. 


6 Minimum Requirements of Solution 

6.1 System Architecture Requirements 

6.1.1 Scalability 

Dynamic or rule based ability to scale the system within servers, across servers without 
inherent bottlenecks and code changes. Ability to scale across data centers. 

The system shall have ability to scale dynamically within a server depending upon 
the load. 

• The system shall have ability to add nodes dynamically without bringing the system 
down. 

• system shall have ability to utilize dynamically increased-CPU, RAM and storage. 

• The system shall have ability to utilize network bandwidth provided through multiple 
interfaces. 

• The system shall have ability to load balance across servers 

■ The system should not have a single point of failure and inherent design bottlenecks 
that stops it from scaling. 

6.1.2 Security 

Ability to secure all data from thefts, tampering, unwanted modifications, network attacks, 
and other security threats using physical and logical measures as per UIDAI specified 
security and data protection policies. 

The solution shall support: 
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• storing primary data in encrypted fashion 

• profile based encryption schemes 

• secure communication protocols while communicating with external components 

• Communication with only the UID application. 

• only authorized users to access appropriate data 

% 

• changing the encryption schemes dynamically periodically 

• integration with external security components 

• configuring Access Control Lists 

• running services without super user privileges 

• Auditing all access and modifications (by any user) to biometric data and make these 
audit trails available. Audit trail should be stored 


6.1.3 Interoperability • 

Ability to interoperate with other systems/services within and across any open interfaces 
and ability to continually re-factor and/or replace specific components without affecting 
rest of the system. 

The solution shall support: - 

• the open standard protocol based communication 

• command line based interface for interaction 

• re-factor/replace individual services without bringing the whole system down. 

• all APIs and interfaces defined by UIDAI as part of biometric vendor integration 
specifications. 

• automated integration from external management products such as systems 
management, network management, and other tools 


* 

6.1.4 Manageability 


Ability to manage end-to-end solution and its components to ensure solution health and 
SLAs using external data center management toots. 


The solution shall support: 
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• monitoring of its services using management tools 

• ability to bring its services up and down 

• monitoring its CPU/network/storage utilization 

• monitoring the response time of individual services 

• maintenance of its services without affecting client access 

• continuous availability of its services even during regular management activities 



6.1.5 Availability 

Ability of the solution to be up and running over long periods of time and ensure continuous 
availability. 

The solution shall support: 

• high availability of its services across servers and DC 

• integration with technologies that provide application high availability 

• integration with technologies that provide data replication to have data high availability 

• continuous availability of its services even during regular management activities 


6.1.6 Upgradeability 

Ability to seamlessly upgrade services, components, and modules without affecting services 
and open interfaces. Ability to upgrade without bringing down the solution. 

The solution shall support: 

• upgrade Of individual modules without bringing the solution down. 

• backward compatibility 

• upgrading using third party software delivery systems 

4 

• reverting back to original configuration in case Of an upgrade failure 

• reverting back to old configuration after a successful upgrade 

6.1.7 Installation and Configuration 
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Ability to configure the solution using wizard and Other end user tools. Ability to install the 
solution using install script. 

The solution shall support: 

• integration with change management system 

• integration with software delivery systems 

• installation and configuration without super user privileges 

6.1.8 Maintainability - 

4 

The solution shall have the: 

• Ability to continuously maintain, enhance, re-factor solution without 
breaking other parts. 

• Ability to support maintenance, enhancement and refactoring the solution 

» 

without breaking other parts 

6.1.8 Open Standards Based 

Technology choices should be based on open standards and widely adopted frameworks as 
long as they meet the needs of the system. 

The solution shall have: 

• technologies that are based on open standards 

• frameworks that are widely adopted 


6.1.10 Cloud Enabled 

Technologies that support deployment on a virtualized platform. 

The solution should support: 

• The ability to deploy and run the application within a private cloud platform 
to take advantage of next generation cloud features. 

• running services in virtualized environments 

• metering of CPU, network and storage utilization 
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• throttling of CPU, network and storage utilization 

• multi client capable services 



6.1.11 Administration 

Ability to administer the ABIS during its operation. 

The solution should support: 

• ability to administer the solution with minimal user intervention with well 
defined user interfaces and access policies 

• easy to use operator interface 

• command line for all administrative operations 

• role based administration 

• automation of administrative tasks 




6.1.12 Logging and Reporting 

m 

Ability to log and report at a sub-system level state, health of the solution. It shall also log 
different events encountered by the subsystem. 

The solution shall have: 

• The ability to log and create reports to know the current state of the solution 
and improve the quality of different services offered by the solution 

. a mechanism to configure the logging level for different modules 

• a mechanism to rotate the logs based on polices 

• a mechanism to search through the logs with different filters 

• a mechanism to integrate with alert management tools 

i 

• a mechanism to generate reports on various performance indicators 

• a mechanism to integrate with external reporting tools 


6.1.13 Storage Access 

Ability to use heterogeneous storage environments. 
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The solution should: 

• 0 

• work in heterogeneous storage environments with data partitioned across 
servers 

• function with storage getting provisioned using heterogeneous storage 
technologies like NAS/SAN/DAS 

• access only the data to which it was given access 

• support data partitioned across different servers 

6.1.14 Backup/Restore 

Ability to provide backup and restore of the persistent data 
Solution should have: 

• capability to backup and restore the data generated in the solution 

o ability to backup of the data generated in the solution while continuing to 
process service requests. — t 

o allowance for incremental/differential/full backup methods 
o ability to take backup of application consistent data 
o proper functioning after a restore operation 
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S.2 ABIS 

6.2.1 Functional requirements 

A0 IS will provide the following functions 


6.2. 1.1 Enrolment Related 


1 insert- This function is used to insert biometric data (templates) into the reference 
database without performing biometric matching. Obtain the biometric and 
demographic data for the supplied ID, process the biometric samples as required by the 
biometric solution and store [templates) in a reference database. The function will 
internally invoke segmentation, feature extraction and template generation. 

2. Identify: This function is used to perform de-duplication and identification (in case of 
lost UlD of an enrolled person) across entire or sub-set of the database. It compares t e 
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query data for the supplied index against the entire reference database, sub-set of the 
database, a set of supplied indices or a single supplied index. Incoming query data 
samples always consist of images, possibly cropped and losslessly compressed. The 
function returns a candidate list of transaction numbers of potential duplicates above a 
threshold and associated comparison scores scaled on the interval [0,100) with 0 being 
the measure of least similarity. 

3. Delete: This function is used to remove an ID from the reference database. The removal 
need could arise for variety of reasons. 

Updating biometric data in the reference database will be accomplished by inserting a new 
record. On rare occasion, the ABIS will be subsequently directed by the UID application to 
delete an existing record in connection with the update operation. 

6.2.1.2 Management related 


Management related functions will be at two levels of security and allow the ABIS 
component to be managed using programming interface. On the higher security level, the 
key required functions include 

1. Shutdown. The ABIS component is required to shut itself down. 

2. Clear. The ABIS component is required to delete all the data from its reference database 
and clear all queues. 

3. Configure. At the time of initialization, ABIS component is provided with vendor specific 
information to configure itself. The information will include operating characteristic. 

Pinging the system is at the lower security level. Additional functions required for system 
management, configuration, logging and reporting should be provided under the 
appropriate requirements. They are not part of the API at this time but accessible through 
the system management console. 

6.2.1.3 Verification related 


1. Verify. Verify is a special case of Identify mentioned above where only 1:1 comparisons 
are performed. The ABIS is sent a query consisting of a fingerprint or iris image Or a 19794-2 
compliant fingerprint template, and the index number of the enrolment record to which the 
query is to be compared. A scaled comparison score and a "match/non-match" decision is 
always returned. Fingerprint verification utilizing 19794-2-compliant templates will be done 
without use of proprietary extended data. 
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.2.2 Datastorage requirement 

ersistent data including ,he reference database may be stored ,n Indus,nr s»»d«dRMW 
r in file system. In both cases, the vendor should provide export tools to allow access 
he data in situations including but no, limited change of vendor, database synchrony ' • 

ackup. upgrade or maintenance. The exported data should be in industry standard format 

eadable using open source tools. 

,BIS should have necessary backup and restore functions for routine system administration. 

\ copy of the reference database will be stored in a industry standard database or f.le 
;ystem existing at a separate location. Therefore BSP shall provide all necessary assistance 

: orthe same. 


5.2.3 Logging and monitoring 

Capability to log transactions a, the component interface level, should be implemented 
such that il allows dynamic starting and stopping of this transaction logging service, 
level of logging should be controllable using a configuration parameter. 

The audit system should be centrally managed and should be secured against tampering. 
The system Should be able to capture before and after values from transact,on logs, 
privileged user audits, raise alerts on suspicious activity. It should provide security facilrhes 
for role segregation within audit brganitation in terms of administrator, auditor etc. These 
audit logs should be kept per the retention policy of the UID application Until UIO s 
retention policy is published, BSP will retain all logs as specified in indicative list below.. . 

Audi, and logging system should be scalable and should have the space to grow. The system 
should be flexible to accommodate new audit requirements in the future. 


6.2.3.1 ABISlog 


• Template generation Time 

. Total time taken for multi modal matching process (in seconds), 

. Matching algorithm throughput, 

. Matching scores of each matcher including Fusion and the decision. 
. Percentage of automated identification vs. manual intervention rate 
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6.2.5 Security Requirements 

All persistent personal information data will be encrypted. 

Encryption password or user name/password should be required for data access. 

ABIS will not have access and should not try to access any network resources except the 
referenced by the URLs provided through the API. 

All backup data shall be stored in encrypted format using a key(s) available to the UIDAI. 

6.2.6 Operator Interface Requirements 

AH administration and configuration features should be available through graphical Ul (m 
addition to command level access). 

6.2.7 Platform requirements 

AB!S should be compatible with Linux OS with both 32 and 64 bit support on X86 COTS H/W 

• . • 

6.2.8 Standards 

4 

ABIS will comply with most recent applicable ISO standards and Biometric Standards for UlD 

Applications 

6.3 Multimodal SDK 

The SDK is a set of libraries that provide following functions. 

6.3.1 Fingerprint 

1 Segmentation. Slap sequence check / segmentation will be used to check if the claimed 
sequence: right or left slap is correct and also to visualize the segmentation result and 
use it for the feature extraction. It segments slap image of 2 to 4 fingers into respective 
digits with associated confidence level of segmentation accuracy. It will allow 

specification of missing or extra digits. 

2 Quality check. The capture quality check will be used to determine if the enrolment 
software needs to re-capture and provide corrective action; for example finger is 
misplaced on the scanner. Quality check must be able to provide actionable feedback 

(e.g., "move finger to the left")- 
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3 . Coffipression/decompression and format conversion: For verification applications, 
transmission of single fingerprints compressed by WSQ compression will be required, 
with decompression upon receipt by the verification function. During enrolment, the 
SDK is required to convert the image format such as from RAW to PNG. The SDK will 
supply WSQ compression and de-compression algorithms with tunable compression 
ratio 

4. Template generation. The SDK should be able to generate ISO/IEC 19794-2:2005 
compliant templates that have been tested to be interoperable with other third party 
matchers in an independent test. 

5. Identification (l:N, ew ). The SDK will be able to compare features extracted from a FP 
image against a set of reference templates and return a scaled comparison score 
between [0,100], with 0 indicating least similarity. 

6. Verification (1:1). The SDK will be able to compare features extracted from a FP image 
against a specified reference templates and return a scaled comparison score between 
[0,100], with 0 indicating least similarity. 

63.2 Iris 


1. Quality check. The capture quality check will be used to determine if the enrolment 
software needs to re-capture and provide corrective action, for example image is out of 
focus or has motion blur. Quality check should be able to provide actionable feedback. 

2 . Segmentation: The SDK will be able to extract KIND_VGA, KIND_CROPPED, and 
KIN D_CROPPED_AND_MASKED from ocular image. 

3 . Compression/decompression and format conversion: The SDK will be able to convert 
image from one format to another (for example, BMP to KIND_V6A) 

4 Feature/Template generation: The SDK will be able to extract and store a proprietary 
o template from the segmented iris image. 

5. identification (l^f,*,). The SDK will be able to compare features extracted from a query 
iris image against a set of reference templates and return a scaled comparison score 
between [0,100], with 0 indicating least similarity. 

6. Verification (1:1): The SDK will be able to compare features extracted from a query iris 
image against a specified reference template and return a scaled comparison score 
between [0,100], with 0 indicating least similarity. 

6.33 Face Photo 
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1. Automatic Capture. Automatic capture will analyze video frames from the camera, 
provide the actionable feedback, and select the best frame. 

1 . Quality check. The capture quality check will be used to determine if the enrolment 
software needs to re-capture and provide corrective action. 

. 3. image enhancement. Enhancement such as face cropping will automatically find the 
face in the photograph and crop/resize the image to an ICAO compliant format. The 
SDK should not carry out any gray-level manipulations. 

4. Feature/Template generation: The SDK will be able to extract and store a proprietary 
template from the segmented face image. 

5. Compression/decompression and format conversion. The SDK will be able to convert 
image from one format to another (for example, BMP to JPEG 2000) and compress 

or decompress images. 

6. Identification (l:N few ). The SDK will be able to compare features extracted from a 
query iris image against a set of reference templates and return a scaled comparison 
score between [0,100], with 0 indicating least similarity. 

7. Verification (1:1). The SDK will be able to compare features extracted from a query 

face image against a specified reference template and return a scaled comparison score 

between [0,100], with 0 indicating least similarity. 


6.3.4 Standards requirements 

Ail uncompressed images should be as per UID standards (e-.g., PNG). 

Ail compressed images should be as per UID standards (e.g. WSQ or JPEG 2000) 

6.3.5 Reliability Requirements 

The SDK should perform consistent to the specifications, for all possible data in the specified 
formats. The results should be reproducible On a variety of platforms. The libraries should 
work without any segmentation violations, memory faults or memory leaks. 

6.3.6 Security Requirements 

SDKs should be purely computational libraries and should have minimum system 
dependencies and should not attempt to access any resources such as hardware, files Or 

network. 

6.3.7 User Interface Requirements 
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SDKs should not have any user interface. ' 

6.3.8 Platform requirements 

SDK should support Windows (XP & above) and Linux Os with both 32 and 64 bit support. 





7 Load and Performance requirements 







20 Crore (200 Million) 

records 

10 Lakh (1 Million) 

requests/day (in 24 hours) 

Fingerprint template: 10 
Lakh (1 Million) 

requests/hour 
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Iris image: 

requests/hour 

10,000 




Face photo: 

requests/hour 

2,000 





Accuracy 

False Positive Identification Rate < 0.1% 

for database size of 20 Crore. 

False Acceptance Rate < 0.01% at 
False Rejection Rate < 2%. 


False Negative Identification Rate < 1% 
for database size of 20 crore. 


Response 

time 

No daily backlog 

< 0.1 second average for 

biometric verification using ISO 
FP template while using SDK 1 . 



< 0.5 second average for 

biometric verification using ISO 
FP template while using ABIS. 


SDK matching accuracy rates must meet the FAR and FRR rates required for verification on 
operational data as given above. The SDK licensing is required for 


1 Using standard COTS hardware specified in clause 8. Maximum of two fingerprint ISO templates to 
be matched against ten fingerprint ISO templates. 
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1. Enrolment stations required to perform 200 crore enrolment over the contract period. 

2. Authentication servers required to support peak authentication requests at the 
specified response time level 

3. Adjudication stations required to support FP1R for the enrolment rate mentioned above. 

4. System monitoring and analysis servers for ABIS configuration to support 200 crore DB 
size over the contract period. 



8 Server, Storage and OtEier Infrastructure 

8.1 Supply of hardware by Biometric Solution Provider for the first 1 Crore allotted 
* enrolments 


Biometric Solution Provider, as a part of this project, shall provide all the hardware of 
required capacity for de-duplications of the firstl Crore enrolments. The hardware shall 
include all components, including physical racks, required for performing the required 
services to meet the performance level expectations as stated in Section Ill-Attachment- 
Draft Service Level Agreement. The components of hardware that Biometric Solution 
Provider should include, but not limited to: 

a) Blade Server 

b) Blade Chassis 

c) SAN (Storage Area Network) 


The components should be supplied for deployment of the overall solution at both primary 
site and BCP site in 1:1 configuration 

The minimum expected specifications for the key components that the hardware should 
comply with are provided in Section VI.b. The Biometric Solution provider shall be 
responsible for supply, installation and commission of all hardware supplied along with 
installation and commissioning of the overall solution. 

Tier 3 DC environment facility would be made available for the solution. UIDAI shall provide 
only the datacenter space, power and cooling infrastructure and a standard 10 gbps 
network switch to connect with the rest of ClDR network in the Datacenter. 


The hardware components to be provided by Biometric Solution Provider should adhere to 
following: 


1. Should be compatible with all required interfacing devices and appliances in the 
datacenter 









2. Specifications should allow UIDAI to scale up the infrastructure to 20 Crore 
enrolments and beyond ' 

3. Should be able to interconnect and interoperate with all required interfacing devices 
and appliances in the datacenter 

4. Should comply with the Datacenter standards, policies and procedures laid out by 
UIDAI 

5. Should adhere to BCP strategy laid by UIDAI and should be compatible with industry 
leading replication technologies and backup application softwares available in the 
market presently 

» ■ 

6. Should provide APIs for integration with leading IT infrastructure management 
solutions and comply with policies of enterprise management 

7 . Compatible with the Indian standard power ratings. 

8. The servers configuration of the servers that Biometric Solution Provider shall supply 

should have been field tested for at least 3 months at the release of this RFP 

» 

9. The OEMs of Servers proposed to be supplied should have been in the business of 
manufacturing the servers for at least 4 years 


In case if any of the component does not comply with the UlDAJ standards or is not in line 
with future direction of UIDAI, UIDAI will have the right to ask for replacement from the 
biometric solution provider and Biometric Solution Provider shall provide the replacement 
at no additional cost. 

Table below provides some of the Datacenter environment constraints that the Biometric 
Solution Provider should note while finalizing the Hardware Infrastructure to be provided. 




Preferable Rack Size 

» 

42 U /19 inch high, 600 mm 
wide, 1000 mm deep 

Allocated power per Rack 

7 KVA 


The bidder should, as part of the Technical Proposal, provide details on the hardware 
supplied that shall include the following: 
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1. Logical and deployment diagrams with details on number of blades per chassis, 
chassis per rack, power and cooling requirements, connectivity for n/w and storage. 

2. Specifications of blade servers, blade chassis and Storage to be provided by provided 
responses in Section Vl.b 

3. Bill of Quantity of all components and peripheral devices in terms of quantity and 
specifications without the mention of any prices as per Annexe 4.4.3 in Section IV 

4. Storage requirement for backup 

5. Details on Warranty period and Annual Maintenance from the hardware OEM for 
each of the component 

The payment for hardware supplied by the Biometric Solution Provider shall be a fixed 
amount as per the payment terms stated in Section 111 — General Conditions of Contract 
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Provision of System and Other Softwares: 

As part of overall Solution to be installed, configured and maintained. Biometric Solution 

Provider shall also factor the required systems softwares that shall include, but not limited 
to, the softwares indicated in Section Vl.c. 

All softwares proposed shall be considered as a part of the black box ABIS solution and 

the associated cost shall be factored as part of De-duplication services cost as mentioned 
in Clause 25 of Section II. 

8.2 Supply of hardware by UIDAI after first 1 Crore allotted enrolments 

cLIT fr°7; “ SOlU,i0n PrOVider Sba " ^ th * hardware for the 

capacity of first 1 Crore enrolments. For enrolments after thp fircr ir i 

UIDAI or UIDAI nominated agency shall provide the Blade Servers or eq^a^o^'t- 

ssr ,he 3 or ~:r ne 
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From first 1 Crore allotted 
enrolments transactions 
to 5 Crore allotted 
enrollment transactions • 



From first 5 Crore allotted 
enrolments transactions 
to 10 Crore allotted 
enrollment transactions 

* **»■•"*“ 11 


From first 10 Crore 
allotted enrolments 
transactions to 20 Crore 
allotted enrollment 
transactions 


'vT’.V'fi 


K&! 


Up to 20 Blade Servers or J Up to 10 TB 
equivalent computing 
power 


Up to 80 Blade Servers Or I Up to 50 TB 
equivalent computing 
power 




Up to 200 Blade Servers or | Up to 100 TB 

equivalent computing 

power 


The Biometric Solution Provider shall raise the request of additional servers and/or storage 
a. leas. 3 months ,n advance for UIOA, or the nominated agency to provision for the lame 

iheTh! 7 Bi0me ‘ riC k Solu,io " Proxid ^ requirement for server and storage during any of 

•a V,r CeedS ,he max ' mum c,uar,ti, v provisioned by UlDAI, the Biometric Solution 
provrder sha compensate UIDA, on the cos, for the additional hardware ,0 be p“ 

torn „s hardware supplier agency along with the associated costs on power cooling 
datacenter space and maintenance charges. ' 

r:r e r d ' addlti °" al incentives ’or using less than prescribed hardware in each 

the r ?'• T r ee,,ng the required " umber ° f a "°‘ ,ed tr3 nsactions, shall be provided to 
the Biometnc Solution Provider. The plan for incentive shall be formulated by UlDAI keeping 

in view pf reducing the Overall cost. PS 

9 Statement of Work 

Please refer to Clause !2 Project Plan a Timelines to gain an understanding on how the 
implementation is envisaged to be carried out. 
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9.1 


Project initiation 



# 

# 






Within 7 Calendar days of award of contract, the BSP is required to do the following: 

a. Mobilize the team for the project. The BSP shall deploy personnel including the Key 
Personnel as mentioned in the Clause 11 Constitution of Team. 

b. initiate the supply of all required hardware and storage infrastructure, including but 
not limited to, servers and storage as required to support 1 Crore enrolment as per 
the minimum requirements stated in Section Vl.b. The BSP shall bring all the 
required hardware as required to support 1 Crore enrolment. 

c. Conduct a kick-off meeting with UIDAI with participation from key personnel 
proposed for the project to discuss the project plan for way forward 

d. Submit a plan for procurement, transportation, installation and commissioning of 
hardware in UIDAl's data centers both Primary and BCP sites located in Delhi and 
Bengaluru respectively. The BSP shall adhere to environment specifications of these 
sites and adhere to the BCP plan. There shall be Zero data loss while switching from 
Primary to BCP site maintained as active-passive with 1:1 capacity. 




# 


e. Co-Ordinate with Data Center service provider and prepare a blue print for 
deployment of hardware, ensure availability of power and other environmental 
facilities in the datacenter 

f. .Set up the required Test and Production environment s for the rollout of PoC. The 
hardware used for Solution Demonstration exercise as part of the RFP evaluation 
process could be used for the rollout of PoC, if found adequate to meet the 
requirements based on expected enrolment transactions. 

g. Begin to supply SDK perpetual licenses of the proposed multimodal SDK to cater to 
requirements as stated in Clause 4. Biometric Solution Components 

h. Support ASDMSA in developing the client enrolment software through provisioning 
licensing, training and services. SDK licenses must not use hardware license key or 
keyed to ID (such as CPU, serial number, Ethernet ID). 



S 9.2 implementation of Solution as Proof of Concept (PoC) 

As stated in Clause 12 Project Plan & Timelines, the BSP shall deploy the solution in the form 
of Proof of Concept (PoC) that shall cater to the early enrolments Of the residents. 


Ip 

m 






f 






■i 


The solution in PoC should cater to early volumes of enrolment. The solution in PoC shall at 
minimum provide: 

* 

a. integration of ABIS component with UID application at server side 

b. integration of Multimodal SDK with Enrolment Client application 

e. Configuration of business rule and application level policies related to de-duplication 
and verification as stated by UIDAI 

d. Perform de-duplication checks (1:N) for enrolment subjects on a reference database 
up to 10 lakhs 



e. Perform biometric verifications (1:1) using the ABIS component for at least up to 

10,000 verifications per day. The full scale solution as detailed in Clause 4 Biometric 

• . • 

Solution Components shall be using Multimodal SDK for the verification services 


The BSP shall rollout the solution after a review and testing of the same UIDAI. The BSP shall 
be responsible for application availability while in production and shall deploy the solution 
at both Primary and BCP sites and adhere to BCP plan including data backup and recovery 

Continuous performance monitoring and improvement of the solution in terms of accuracy, 
throughput and optimum resource usage shall be undertaken by the BSP. The learnings 
shall be used towards configuration of the Solution 

The SLAs as stated in Draft Service Level Agreement of the RFP shall not be applicable for 
the solution when in PoC. 

The solution shall be in PoC until the go-live of the full scale solution. The BSP shall be 
responsible for transition from PoC to full scale solution without any data loss and minimal 
disruption Of operations. 

Installation, Configuration and Commissioning of the full scale Solution 
9.3.1 Installation and Commissioning for all Servers 

The BSP along with UIDAI, and datacenter service provider should undertake pre¬ 
installation planning at Primary and BCP sites including but not limited to Rack planning, 
structured cabling, power points, check on utility services, environmental conditions, etc. 

Delivery, installation and commissioning of the hardware servers and related equipment in 
the Datacenter Space provisioned by UIDAI at their Primary and BCP sites. 
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The plan and layout design for the placement of equipment in the prov.s.oned datacenter is 
required to be carried out by the BSP. The BSP should provide an elevation plan for each of 
the Primary and BCP datacenter for housing of the servers and other equipment. 

The plan and layout design shall be developed in a manner so as to optimally and efficiently 
use the resources and facilities available or being provisioned at the respective datacenters 
viz. space, racks, power, air-conditioning, cabling, etc. 

The BSP should co-ordinate with the datacenter provider of UIDA1 in order to prepare the 
plan and develop the layout design. 

The plan and design documents thus developed shall be submitted to UIDAI or its 
nominated agency for appmval and the acceptance should be obtained poor to 

commencement of installation. 

Carry out installation of equipment in accordance with plans and layout design as approved 


by the UIDAI 

Installation and configuration of the software including but not Ifmluit!I to.Operating 
System (OS), System software, etc. on the servers would be responsibility of the BSP. Th 
BSP should also tune parameters for optimal performance of the OS shoufd be earned out. 

Undertake necessary changes to harden the OS to prevent against malicious and 

unwarranted attacks. 

The BSP will install all necessary software infrastructure and middleware including 
Database, Application Seiver software, and tune appropriate parameters in this software to 
ensure optimal performance should also be undertaken. 


9.3.2 Storage Installation and Configuration 

The BSP should undertake study of the application environment in order to plan for an 
Ltegmted storage infrastructure based on SAN. The toning. LUN and voiume creation 
should be decided based on the characteristics of the application. 

Develop an implementation plan, installation and configuration of the SAN array to 
implement the overall solution. 

The deployment of the disk storage shall consists of tasks, including, but not IMttd to 

installation and configuration of SAN design, creation and configuration volumes, LUN, RAID 

of data,I. and undertake tuning exetcise to optimize 

oerformance of the solution. 
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9.3.3 Setting up of Testing, and Production Environments 

BSPs shall set up Test and Production environments. The environments are to be 
established to serve various purposes along the biometrics solution lifecycle. The following 
section describes each of these environments. 


The BSP shall undertake setting up of infrastructure related to propose solution by verifying 
the infrastructure being deployed, installed and commissioned and verify the entire setup 
once before activating the environment. The BSP shall also periodically verify the adequacy 
of the environments during operations after the setup and notify UIDAI on the any issues 
requiring action. 

9.3.3.1 Production Environment 

Production environment shall compose of racks containing servers, storage, 
communications equipment, security devices as required for by the proposed Biometric 
Solutions. The production environment shall be common for the entire ClDR infrastructure 
used in production that includes infrastructure from other BSPs. 




9.3.4 Configuration and Integration of the Solution 


The BSP shall use all the learnings from the Proof of Concept (PoC) towards configuring the 
solution to meet the performance and load requirements during the contract period. 

The BSP shall undertake the following as part of Solution configuration 

a. Configure the solution to comply with the UIDAI policies and other business rule and 
application level policies as stated and finalized by UIDAI 

jo configure / tune the AB1S solution and underlying algorithms in order to meet the 
performance requirements as stated in Attachment 1 - Service Level Requirements 
considering the expected increase in enrolments and growth of the reference 
database 

c. Configuration of ABIS solution's own internal persistence/database component with 
adequate back- up and recovery in compliance with UIDAI BCP plan and data backup 
and recovery strategy. 

d. integration of ABIS component with UID application at server side 
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Assist UIDAI and ASDMA with integration of Multimodal SDK libraries with UlD 
application modules related to verification. The Multimodal SDK (server license 
component) shall be used for Biometric verification (1:1). 

Assist UIDAI and ASDMA undertake Integration of Multimodal SDK with Enrolment 
Client application, adjudication and monitoring module. 

Provide training to UIDAI and ASMDA undertake integration of the ABIS and 
Multimodal SDK with UlD application 

Submit documentation of key configuration settings, business rules and policies 
adopted along with key design and solution features along with user manuals to 

UIDAI for their review and acceptance. 


9.3.5 Testing 

Under the Testing stage, BSP shall carryout Integration Planning & Testing (within the 
solution across modules and third party algorithms and also the external mtegratron with 
apis provided by UlOAl) as well as System Test Planning & Testing phases. Tire following 
sections explain the scope of each phase BSP is expected to perform. 


Integration Planning & Testing 

BSP shall identify the critical modules to be integrated, identify order of integration and 
identify interfaces to be tested. 

Along with planning for system integration, BSP shall develop Ibtegration.test cases and 
include these in integration test plan and submit the same for rewew to UIDAI 
ncp 5h3 || undertake the actual integration activity as per the integration test plan. 
Subsequently, integration testing shall be carried out as per the plan, log all defects foun 
and shall ensure these defects are rectified and re-tested. 

Testing stage shall include testing of the integration of the proposed =olu,ion components 
(Server side ABIS and Client slide SDK) with respective APIs prov.ded by UIDAI. 

The BSP shall be jointly responsible with ASDMA in integration and end to end testing of 
e-ach integration interface at client and server side applications 

BSP shall maintain the integration test plan along with test results 8, defect statistics and 
provide the same to UIDAI, if desired so. 
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BSP submit report on integration for third party audit 


O 



System Test Planning & Testing 

BSP shall plan out a series of different tests, each test having a different purpose, to verify 
that all system elements have been properly integrated and that the system performs all its 

functions and satisfies all its non-functional requirements. 

The inputs for this phase consist of the requirement specification document (SRS) and the 
initial system test plans where as the outputs consist of system test plan and test results. 

As part of system test planning, BSP shall identify features that shall be tested and features 
that need not be tested. 

On successful completion of the Integration testing, BSP shall carry out the actual system 
testing as per the system test plan. 

BSP shall ensure that system testing is carried out by an independent team other than the 
development team. BSP shall setup a separate test environment with test database to carry 

out system testing. 

As part of the system testing, BSP shall carry out Performance testing of the application to 
ensure that the application meets the performance requirements. 

BSP shall maintain the system test plan and test results with defect statistics and provide 
the sarfle to uiDAI. 

BSP shall submit a report on testing to UIDAI for review 

Stakeholder testing (User Acceptance Testing) 

Stakeholder testing consists of formal testing conducted by the-user-group according to the 
test plan and analysis of the test results to determine whether the system satisfies its 

acceptance criteria. 

i. BSP shall prepare a plan to coordinate the User testing activity. 

ii. BSP shall prepare a software release note that contains stepwise instructions 
for UIDAI on how to install the software. The instructions shall include 
information on creating the directory structures, installing source and 
executables, loading data needed for installation and so on. 



The primary responsibility for acceptance testing lies with the user group and 
UiDAI shall coordinate with BSP to ensure necessary support is available to 


the user group. 
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iv. End user/testing group shall document the test cases / scenarios to ensure 
that the defined acceptance criteria are validated during the testing. 

v. The test cases prepared by third party shall be approved and used by UIDAI 
for the purpose of testing 

vi. BSP shall provide support to document the User Test Results along with 
Defects Statistics. BSP shall ensure that defects found are corrected and is 
retested by the end user group. 

vii. The testing shall be taken in iterations till the specified requirements are met 

viii. Test results shall be audited by a third party 

ix. On successful completion of User Testing, BSP shall obtain a formal sign-off 
from UIDAI for solution go-live. 



9.4 Go-live of Solution 

BSP, in coordination with UIDAI, shall prepare setting up the production environment, 
installation of the application in the production environment. 

BSP shall rollout the application. BSP shall coordinate with UIDAI to resolve any problems 
encountered after rollout. All post implementation issues shall be documented and the 
necessary fixes / resolutions shall be implemented by BSP. 

BSP shall ensure necessary support is provided to resolve defects. BSP shall document the 
defects / bugs encountered during this phase as well as document the resolution of the 
same. BSP shall also prepare and maintain a database of Consolidated List of Common 

Errors & their Resolution. 



9.5 Activation of SLAs 

The Biometric Solution Providers shall undertake performance improvement measure for 
the solution until the solution meets the required Solution related performance service 
levels as stated in Attachment 1- Draft Service Level Agreement. After a period of 8 (eight) 
weeks after go-live or on completion of 1 Crore enrolments, whichever is earlier, the 
Solution shall be required to comply with the Service Level Agreements. The BSP shall be 
required to submit an undertaking to UIDAI on formally complying with the SLAs in Order for 
the solution to be finally accepted for future allocation of transactions. Formal compliance 
to SLA is perquisite for the BSP to be considered for dynamic allocation of enrolment 
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volumes. Please refer to Annexure D - Work Allocation and Service Level for more details 
on dynamic allocation of transactions across multiple BSPs selected through this RFP. 


9.6 Requirements Change Management (Pre-implementation) 

UIDAI expects upgrades to occur during the contract period. If there are changes in 

requirements during the contract period post go-!ive, BSP in consultation with UIDAI is 

expected to define a formal process to manage the requirements changes as defined for 
illustration below: 


BSP shall mamtam a change request log to keep track of the change requests. Each entry in 
the log shall contain a Change Request Number, a brief description of the change, the effect 
Of the change, the status of the change request, and the key dates. 

O BSPsha ." assess the effect of the change by performing impact analysis. 

BSP shall maintain the change request log with updated information and provide the same 
to UIDA! as and when desired. 
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S.No 


Range of enrolment transactions Cycle Name 
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3 

2 to 3 Crore transactions 

Cycle 3 

4 

—*- r J -=-— 

3 to 4 Crore transactions 

Cycle 4 

5 

4 to 5 Crore transactions 

Cycle 5 

6 

5 to 6 Crore transactions 

Cycle 6 

7 

6 to 7 Crore transactions 

... . . ,f. ..w t ^ .. . .. 

Cycle 7 

8 

7 to 8 Crore transactions 

Cycle 8 

9 

8 to 9 Crore transactions 

Cycle 9 

10 

9 to 10 Crore transactions- 

Cycle 10 

11 

10 to 11 Crore transactions 

Cycle 11 

12 

11 to 12 Crore transactions 

Cycle 12 

13 

12 to 13 Crore transactions 

Cycle 13 

14 

13 to 14 Crore transactions 

Cycle 14 

15 

14 to 15 Crore transactions 

Cycle 15 

16 

__ L M 

15 to 16 Crore transactions 

Cycle 16 

17 

16 to 17 Crore transactions 

Cycle 17 

18 

17 to 18 Crore transactions 

Cycle 18 

19 

18 to 19 Crore transactions 

Cycle 19 

20 

19 to 20 Crore transactions 

Cycle 20 


# 


# 


u * 


*Note:- No. of allocation cycle shall depend on the rate of actual enrollments 
undertaken during the Contract period 

3. Rules of Allocation 

i. The duration of an allocation cycle shall be 3 (Three) months or till the time of 
completion of 1 (One) Crore new enrolment transactions, whichever is earlier. Each 
allocation cycle can hence have a maximum of 1 Crore enrolment transactions. 


Vrtq 


II. 


lit. 


The enrolment transactions in Cycle 1, i.e., from Zero to 1 Crore Transactions shall be 
assigned to all the Biometric Solution Providers, meaning, each Biometric Solution 
Provider shall perform successful de-duplication check on the same 1 Crore subjects. 

From Cycle 2 onwards, daily volumes shall be allocated separately to Biometric Solution 
Provider in proportion Of the total volumes per day. 
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iv. The proportion of allocations across Biometric Solution Providers shall remain fixed for 
the allocation cycle under consideration. The maximum allocation of enrollment 
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xiv. False Negative Identification" A term applying to de-duplication transactions only. An 
incorrect decision of a biometric system that an applicant for a UID, making no attempt 
to avoid recognition, has not previously been enrolled in the system, when in fact they 
have. This failure to match might be caused by any algorithm in use by the system 
(segmentation, comparison, binning, quality, etc.). 



xv. "False Negative Identification Rate (FNIR)" A term applying to de-duplication 
transactions only. The ratio of number of false negative identification decisions to the 
total number of enrollment transactions by enrolled individuals. This rate is expected to 
depend upon the database binning/partitioning used to meet throughput requirements. 
Enrolled database size will be specified. As no failure-to-enroll decisions will be 
permitted for residents with any of the 12 biometrics available, failure-to-enroll rates 
are presumed to be zero and will not be considered in computing the false negative 
identification rate. Data from residents with none Of the 12 biometrics will be 
exempted from the calculation of this rate. 


2. Dynamic Allocation 


i. UIDAI shall allocate the transaction volumes related to enrolment to the selected 
Biometric Solution Providers based on the performance of their respective solution, as 
deployed, on following parameters respectively: 

a. Accuracy, measured in terms of FPIR and FNIR, of De-Duplication checks 

b. Speed of De-duplication 

c. Hardware Resources used by the biometrics solution 




ii. The total number of enrolment transactions during the contract period is expected to be 
20 Crores and the same shall be divided into multiple cycles called as Allocation Cycle 
with duration of 3 months per cycle. Following indicates the distribution of enrolment 
transaction volumes across allocation cycle. An allocation cycle can have a maximum of 
1 Crore enrolment transactions 


Table 1 - Allocation Cycles* 
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X. 



"Non performance of a Biometric Solution" If the solution provided by a Biometric 
Solution Provider does not meet even minimum limit of accuracy for de-duplication in a 
cycle, then it is treated as non performance of the Biometric Solution. Any drop in 
accuracy of the de-duplication checks by the Biometric Solution below certain limits 

i 

shall be treated as non performance of the Biometric Solution Provider. The accuracy 
shall be measured by service levels under category 'Accuracy' in Clause 7.2.1 Biometric 
De-Duplication - Performance Levels effective from Release 2 of Draft Service Level 
Agreements. A measurement of service level below the stated limits shall be treated as 
non performance of the Biometric Solution Provider. 

"Transfer of Volumes" Assignment of a certain part or the whole share of the enrolment 
transaction volumes o‘f a Biometric Solution Provider for the next cycle, to one or more 
Biometric Solution Providers before the commencement of the next cycle in addition to 
their respective shares of volumes. 

"Probation" A period during which the Biometric Solution Provider cannot undertake its 
normal operations based on allocation of enrolment transaction volumes. During 
Probation, only a limited percentage of its normal allotted share of enrolment 
transaction volumes is provided to the Biometric Solution Provider. The period of 
probation is equal to the duration of the next Allocation cycle in which it is kept under 
probation. 

"Rehabilitation" A period during which the Biometric Solution Provider cannot 
undertake its normal operations. During Rehabilitation, the Biometric Solution Provider 
shall not receive any allocation of enrolment transaction volumes from the next cycle 
onward unless it successfully meets the acceptance criteria of the testing conducted by 
UIDAI after a certain period of time. 



XII. 


XIII. 


"False Positive Identification" A term applying to de-duplication transactions only. An 
incorrect decision of a biometric system that an applicant fora UID has previously been 
enrolled in the system, when in fact they have not. 

"False Positive Identification Rate (FPIR)" A term applying to de-duplication 
transactions only. The ratio of number of false positive identification decisions to the 
total number of enrollment transactions by un-eprolled individuals. This rate is expected 
to depend upon the size of the enrolled database and the database binning/partitioning 
used. Enrolled database size will be specified. 
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Work Allocation & Service Level 


1. Allocation of Transaction Volumes to Biometric Solution Providers 
1.1 Overview 

i. UfDAI shall select three Biometric Solution Providers for the undertaking the scope of 
work as stated in Annexure E - Scope of Work. Based on the estimates of expected 
demand for enrolments during the contract period, UIDAI-shal! adopt a metho'd of 
dynamic allocation of enrolment transactions to the selected Biometric Solution 
Providers. 




1.1.1 Definitions of Terms 

i. 1 Crore = 10 million 

ii. 1 Lakh = One Hundred"Thousand 

iii. "Biometric Solution Provider" The party who is awarded the contract, on being selected 
using the process stated in the RFP, to provide services as mentioned in the Annexure E 
- Scope of Work. 

iv. "Enrolment transactions" The transaction to perform de-duplication in order to check if 
there exists any duplicate(s) for the subject being enrolled 

v. "Allocation Cycle" The period for which the allocation of transactions volumes to 
Biometric Solution Providers remains fixed. The duration of the cycle shall be 3 (Three) 

. months or till the completion of 1 (One) Crore new enrolment transactions, whichever is 
earlier. Each allocation cycle can hence have a maximum of 1 Crore enrolment 
transactions. 

vi. "Allotted Enrolment transactions" The transaction allotted to a Biometric Solution 
Provider to perform de-duplication in order to establish if there exists any duplicate(s) 
for the subject being enrolled 

vii. "Normal Operations" The regular course of operations whereby the Biometric Solution 
Provider receives it allotted share of enrolment transaction volumes based on 
computation of allocation among ail the Biometric Solution Providers 
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Annexure D 
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limit 



Resolution of >= 96 to < 97 % Of the total calls within the specified 

5 



limit 




Resolution of >= 95 to < 96 % of the total calls within the specified 

6 

«> 


limit 
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Resolution of < 95 % of the total calls within the specified limit 
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8. Signature 

IN WITNESS WHEREOF, the parties hereto have caused this Service Level Agreement to be 
executed by their respective authorized representatives as of the date first written above. 


Signed, Sealed and Delivered for & 
on behalf of M/s1-1 Identity 
Solutions Operating Com| 

Private Limited 


Signed 


Name: Machie 



Designation: Technical Officer 

Date: August 24 th , 2010 
Place: New Delhi 


Signed, Sealed and Delivered for and on 
behalf of the President of India acting 
through the Director General, Unique 
Identification Authority of India. 

Signed 

Name: B. B. Kanawa®. ^ unite- 

, "i***** *£££, 6w»;. 

De^ignationrWiSti^^li^^tortVen^) 1 ' ' ° 



,th 


Date: August 24'", 2010 
Place: New Delhi 
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presence 
Ctt-A- 

Sigfrtid 

Name: Kalidindi R 
Designation: Director, Business 
Development, LI ID 
Date: August 24 th , 2010 
Place: New Delhi 


In the presence of: 

Signed 

Gene&Jom^ ^ De«* 

Date: 7*010 

Place: New Delhi 
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Measurement 

Definition Target 

Severity Level 

i Reporting 
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j Data Quality 
j Monitoring & 
Reporting 

I 
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Refer Annexure E - Scope of Work I Less than 100% 

| j adherence to 

! time lines 

l 

j specified in 

1 Annexure E, 

I Scope of Work 

j 6 ' ' .. ""■■■ 
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MIS reporting 

J 

. 

Refer Annexure E - Scope of Work j Less than 100% 

• adherence to 

1 

! time lines 

! 

i specified in 

* : 

i Annexure E, 

| Scope of Work 

~6 

• 

1 Incident Reporting 

? 

1 

< 

r 

» 

• 

! 

1 

1 

* 

» 

... 

Refer Annexure E - Scope of Work j Less than 100% 

| incidents to be 
j provided to 

i Purchaser with' 

! 

j in 1 hour with 

s 

j the cause, 

i 

' action and 1 

i 

j remedy j 

~S~ 

7.4. Trouble Ticket/Issue Resolution 

i. "Resolution Time" means time taken {after the trouble call has been logged on the 


helpdesk), ip resolving (diagnosing, troubleshooting and fixing) or escalating (to the 
second level to respective Vendors, getting the confirmatory details about the same 
from the Vendor and conveying the same to the end user), the Services related 
troubles during the first level escalation. 


ii. Provisioning of standby, if required, should be done along with associated data being 
restored, services reinitiated and SLA conditions being met. Final Resolution shall be 
deemed to be complete only after the Original equipment is replaced / reinitiated 
along with data being restored to the correct state and services are resumed. 




Resolution 

Time 

Target 

Severity 

Level 

30 minutes 

Resolution of 98% of the total calls within the specified limit 


Resolution of >= 97 to < 98 % of the total calls within the specified 
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Measurement 


Definition 


! 


Resource availability 
for Help Desk 
specified in 
Annexure E, Scope 
of work during 
various phases of 
the project 


| No. of shift days for which resource 
I present at the designated location / 
1 Total no. of shift days 


Target 


Severity Level 
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I 99% averaged 
| overall 
| resources 

i 

I designated for 
| Biometric 
! Supplier 

4 

j services and 
i calculated on a 

I 

| monthly basis 




r>=97 % to < 99% 

i 

j averaged over 
• all resources 
; designated for 

i 

i Biometric 
i Supplier 
! services and 

i 

! calculated on a 

( 

j monthly basis 
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>=95 % to < 97% j 8 

t 

averaged over j 

all resources 1 

designated for j 

Biometric ! 

i 

Supplier | 

S services and i 

i ! 

’ calculated on a | 

j ! 

monthly basis j 

! j 

« • 

i < 95 % averaged I 9 

» ; 

! over all I 

f resources i 

i \ 

j designated for 
i Biometric ; 

i i 

j Supplier j 

1 services and 
S calculated on a j 

■ i 

i monthly basis | 
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7.3. Operations 


Measurement 


Manpowe r Availabifi 

. . l f ***** . •- au t» 

; Resource availability 
| for Support and 
j Maintenance of 
| Application specified 
| in Annexure E, 
j Scope of work 
j during various 
! phases of the 

f 

project 


Definition 


No. of shift days for which resource 
present at the designated location / 
Total no. of shift days 


Target 


Severity Level 


* * * * fY rrt i g 


j 99% averaged 
I overall 
' resources 
designated for 
Biometric 
Supplier 
services and 
calculated on a 
monthly basis 

>=97 % to < 99% 
averaged over 
ail resources 
designated for 
Biometric 
Supplier 
services and 
calculated on a 
monthly basis 


I 

f 

I 

i 7 

I 
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; >=95 % to < 97% | 8 
i averaged over j 
j all resources j 

I designated for 

’ < 

j Biometric 

i 

j Supplier 
| services and i 

j I 

; calculated on a 
I monthly basis 


< 95 % averaged 
over all 
resources 
designated for 
Biometric 
Supplier 
services and 
calculated on a 
monthly basis 


i 
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Measurement Definition 


Target 
(for reference 
database size 
between 1 and 2 

Crore) 


Consequence 


1. False Match 
Rate (FMR) 



FMR = (Number of 
verification 
transactions in the 
day resulting in a false 
match)/ (total number 
of transactions). 


False Non 
Match (FNMR) 


FNMR = (Number of 
verification 
transactions resulting 
in a false non match 
in the day)/ (total 
number). 


<= 0.01% for all levels of verification 
measured pe r allocation cycle 

> 0.01% and <= 0.1% for all levels of 
verification measured per allocation 
cycle 

> 0.1% and <= 1% for all levels of 
verification measured per allocation 
cycle 


> 1% for all levels of verification 
m easured per allocation cycle 
<= 2% for ail levels of verification 
measured per allocation cycle 

> 2% and <= 3% for all levels of 

verification measured per allocation 
cycle ___ 



> 3% and <= 4% for all levels of 
verification measured per allocation 
cycle 

> 4% for all levels of verification 
measured per allocation cycle 


Remedy for 
consequence 


None 


Liquidated damages of severity 
level: 6 


Liquidated damages of severity 
level: 8 

Liquidated.damages of severity 
level: 9 
None 


Not Applicable 


Not Applicable 


Not Applicable 


Liquidated damages of severity 
level: 6 


Not Applicable 
Not Applicable 


Not Applicable 


Liquidated damages of severity 
level: 8 

Liquidated damages of severity 
level: 9 


Not Applicable 


Not Applicable 
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2. Performance Level for allocation cycles with total enrolment tr ansaction volumes above 2 Crore 

a. The Performance Criteria would be the same as those for cycle with total enrolment transaction volumes between 1 Crore and 
2 Crore. 

b. However, the Purchase reserves the right to revise the targets for the performance criteria for subsequent cycle of 1 Crore 
enrolments (from 2 Crore enrolment transaction volumes onwards) 
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Measurement Definition 



11. Availability 


Uptime 


Target Consequence 

{fur lefesume 

database size 
between 1 and 2. 

Crore) 


seconds and less than or equal to 2 
seconds measured on a monthly basis 

Verification Level * Medium: More 
than 1 seconds and less than or equal 
to 2 seconds measured on a monthly 
basis 

Verification Level - High: More than 1 
seconds and less than or equal to 2 
seconds measured on a monthly basis 


r. *■ 



Uptime = (1 - 
[(Downtime)/ (Total 
Time - Maintenance 
Time)}} 





Minimum 99% up time measured on a 
monthly basis 


>=.99 to < 98% up time measured on 
a monthly basis 


>= 98% to <97% up time measured on 
a monthly basis 


>= 97% to <96% up time measured on 
a monthly basis' 


>= 96% to <95% up time measured on 
a monthly basis 


<95% up time measured on a monthly 
basis 



















1. Response Tforie 
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Response Time 

Response Time = 

Verification Level - Low: Less than or 

None 

Not Applicable 


’ per verification 

(Number of 

equal to 0.5 seconds measured on a 

i 

* 


check 

Verification checks in 

monthly basis 


. 

n ■-: 


24 hours}7 {[86400 




C •' ';" 

-■* . . . * 


seconds - idle time 

Verification Level - Medium: Less than 



:• c 

• :- . : . n . 

. 

with no verification 

or equal to 0.5 seconds measured on 



V r-J 

: w 

i 

i 

transaction}} using 

a monthly basis 


- 

* r 

.: ■ X 


biometric based 
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verification 

Verification Level - High: Less than or 
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equal to 0.5 seconds measured on a 

• 


< -. CJ 

r - V .V <” * 
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monthly basis 


• 
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- — - • 



. Verification Level - Low: More than 

Liquidated damages of severity 

Not Applicable 

*> 



0.5 seconds and less than or equal to 

level: 6 





1 seconds measured on a monthly 



* 

* 



basis 






Verification Level - Medium: More 

• 


» 

; 


than 0.5 seconds and less than or 

■ 





equal to 1 seconds measured on a 



/■?M\ XV 

wV\ r 



monthly basis 




) 


Verification Level - High: More than 






0.S seconds and less than or equal to 



9 



1 seconds measured on a monthly 






basis 


‘ 
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Verification Level - Low: More than 1 

Liquidated damages of severity 

Not Applicable j 
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Measurement 


Definition 


Target 

(for reference 
database size 
between 1 and 2 
Crore) 


<9S% up time 
measured on a 
monthly basis 


Consequence / Severity in 
case of Liquidated damages 


Remedy for consequence 


liquidated damages of 
severity level: 9 


. Resources Peplpyed* 


1. Total amount 
of hardware 









V » yv - H 


Relative number of 
server nodes of 
identical 

configuration used 


Least among all the 
Biometric Suppliers 


> Hardware cost 
provided by UIDAI 


Will impact allocation of 
transaction volumes in the 
next allocation cycle 


Not Applicable 


■>. %k\' 


r j& 






Not Applicable 


Biometric Supplier to 
t compensate UIDAI for every 
additional hardware 
purchased ._ 


Not Applicable 


2. Performance Level for allocation cycles with total enrolment transaction volumes above 2 Crore 


a. 


b. 


The Performance Criteria would be the same as those for cycle with total enrolment transaction volumes between 1 Crore and 
2 Crore. 

However, the Purchase reserves the right to revise the targets for the performance criteria for subsequent cycle of 1 Crore 
enrolments (from 2 Crore enrolment transaction volumes onwards} 



|\7.2.2.Biometric Verification - Performance Levels effective from Acceptance of Solution 

Note: There are no Biometric Verification (1:1) Performance Levels defined under SLA prior to acceptance of the Solution 
1. Performance Level for allocation cycle with total enrolment transaction volumes between 1 Crore and 2 Crore 
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1. Relative 
Response 
Time per De- 
duplication 
check 


111. Availability 

1. Uptime 




Response Time = 
(Number of De- 
duplication checks in 
24 hours)/ {[86400 
seconds - idle time 
with no de- 
duplication 
transaction] * Total 
number of CPU cores 
used} 


Uptime = {1 - 
[(Downtime)/ (Total 
Time - Maintenance 
Time))) 


Least among all the 
Biometric Suppliers 


Minimum 99% up 
time measured on 
a monthly basis 
>= 99 to < 98% up 
time measured on 
a monthly basis 
>= 98% to <97% up 
time measured on 
a monthly basis 
>= 97% to <96% up 
time measured on 
a monthly basis 
>= 96% to <95% up 
time measured on 
a monthly basis 


CP C £ 


\ /py 

# • 9 1 
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continues to remain 
below stated target%, the 
Biometric Solution shall 
be kept under 
Rehabilitation 

None 

• Biometric Solution kept 
under Probation 

• Only 50% of its allotted 
shared of enrolment 
transactions allotted in 
the next allocation cycle 

• If the FNIR of the 

. Biometric Solution 
continues to remain 
below state target%, the 
Biometric Solution shall 
be kept under 
Rehabilitation 


Not Applicable 

Testing after Probation Period of 6 (six) 
months 

Note: During Rehabilitation, Biometric 
Supplier may choose to undertake 
Testing before the expiry of Probation 
Period. However, the cost of such early 
testing shall be fully borne by the 
Biometric Supplier 
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7.2.1.Biometric De-Duplication - Performance Levels effective from Acceptance of Solution 


i. Note: There are no Biometric De-Duplication Performance Levels defined under SLA prior to acceptance of the Solution 
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1. Pe rformance Level for allocation cycle with total enrolment transaction volumes between 1 Crore and 2 Crore 


C 0 



Measurement Definition 
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»r- ;T 

IV % 
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,7 o 
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Target 

(for reference 
database size 
between 1 and 2 
Crore) 


Consequence / Severity in Remedy for consequence 

case of Liquidated damages 
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1. False Positive 
Identification 
Rate(FPIR> 
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FPIR = (Number of 
false positive 
identification 
} decisions in the day)/ 
(total number of 
enrollment 
transactions by 
unenrolled individuals 
in the day). 


<= 0.1% measured 
per allocation cycle 


> 0.1% measured 
per allocation cycle 


None 


• Biometric Solution kept 
under Probation 

• Only 50% of its allotted 
shared of enrolment 

> * 

transactions allotted in 

' * 

the next allocation cycle 

• If the FPIR of the 
Biometric Solution 
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Not Applicable 


Testing after Probation Period of 6 (six) 
months 

I 

Note: During Rehabilitation, Biometric 
Supplier may choose to undertake 
Testing before the expiry of Probation 
Period. However, the cost of such early 
testing shall be fully borne by the 
Biometric Supplier 
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i. Biometric Supplier under probation, can be considered for fresh allocation of 
transaction volumes based on successful testing on accuracy on prior allotted 
transactions as conducted by the purchaser at the end of probation period 

ii. During probation. Biometric Supplier may choose to undertake Testing before the 
expiry of Probation Period. However, cost of such early testing shall be borne by the 
Biometric Supplier 







